Fixing the Log4j vulnerabilities for FileMaker Server
You may have seen recent news, or received customer inquiries, about a major security vulnerability going around the internet. Can you fix Log4Shell on your FileMaker Server? Do you even need to? This post attempts to summarize the latest information available about mitigating the impact of the Log4j exploit on FileMaker Server.
This blog post is based on work from many members of the community, please see the Thanks section for details.
Claris Official response
They have also confirmed that FileMaker Cloud and FileMaker Server 16 and 17 are not susceptible to these specific exploits. You should still prioritize upgrading to FileMaker 19, as all other versions are EOL and no longer supported.
FileMaker Server 16 and 17 do use Log4j 1.2.15 which has a number of other vulnerabilities, including similarly threatening Remote Code Execution, and is no longer maintained. We strongly urge users on FileMaker Server 17 or lower to take mitigation measures (outlined below in “How do I fix it?”), and to upgrade to FileMaker Server 19 as soon as possible.
What are the Log4j exploits (including Log4Shell)?
Log4j is a component that is included within many Java-based applications in order to log application activity and errors.
Log4Shell (CVE-2021–44228) is a zero-day exploit that allows an attacker to trick Log4j2 (v2.0–v2.14) into downloading a malicious package that they want to run on your FileMaker Server.
Shortly after Log4Shell was patched with the release of Log4j 2.15, a related vulnerability was identified and given the designation CVE-2021–45046. The new exploit was patched with the release of Log4j 2.16.
On December 14, CVE-2021–4104 was published, which allows a similar attack as Log4Shell to be run on older versions of Log4j (1.2.x). Log4j 1.2.x also has a number of other security vulnerabilities which will not be patched.
This diagram from the Swiss government outlines the attack method involved, as well as several defensive options that may be applied.
Of the defensive strategies in this diagram, only WAF blocking may be an option with a FileMaker Server behind an appropriate firewall. However, there are reports that WAF filtering is ineffective in the wild due to obfuscation and nesting of the payload.
None of the other strategies can be implemented by a typical FileMaker Server administrator. (For more on mitigation, see “How do I fix it?” below)
Does this affect my FileMaker server?
If you are on FileMaker Server 18, you should still prioritize upgrading to FileMaker 19, as all other versions are EOL and no longer supported. However, you should not need to take any mitigation steps unless you use other software packages that may cause exposure.
The following chart detailing the Log4j inclusion/version information in Claris products is current as of 2021–09–16 08:00 AM US Eastern. Please see Claris’s engineering blog post, “Q&A: Claris products and the Apache Log4j vulnerability” for the latest details.
The community has found the following in various versions of FileMaker Server. This information is included for a more complete “under-the-hood” understanding, but you should rely on Claris’s engineering blog post as the most definitive source of information.
FileMaker Server 10, 11, 12, 13, 14, 15, 16, and 17 include Log4j 1.x, which is NOT susceptible to the Log4Shell exploit. However, Log4j 1.2.x is susceptible to other Remote Code Execution exploits and should not be considered secure. Based on the configuration files in FileMaker Server 17, community members suspect it is safe from the most recent CVE, but it still has other unpatched vulnerabilities. You should take mitigation steps and upgrade to FileMaker Server 19 as soon as possible. [h/t Atsushi Matsuo, Koen Van Hulle, Masayuki Nii, Nick Orr]
There are some traces of Log4j in FileMaker Server 18, but it is not used by normal processes. The traces are in config files included in the Thrift folder and do not appear to include any of the Log4j binary code. Claris has confirmed that FileMaker Server 18 does not include any version of Log4j, and therefore it is not vulnerable to Log4Shell.
There was some evidence based on attribution/licensing that FileMaker Cloud 1.15–1.17 may also use Log4j 1.x, which is not susceptible to the Log4Shell exploit. However, Claris’s official blog post on the Log4j vulnerability states that no version of FileMaker Cloud actually contained the Log4j package. [h/t Atsushi Matsuo]
The Linux version of FileMaker Server 19 (both CentOS and Ubuntu) includes a component called pdfbox that is configured to use Log4j if it’s detected, but doesn’t seem to ship with Log4j in a default installation. If Log4j were installed on that server by some other application, it may be possible for an attacker to leverage pdfbox to execute the Log4Shell exploit. However, testing by the community has been unable to develop a proof-of-concept that could successfully execute an attack against pdfbox even with an unsecured version of Log4j 2.x installed manually. [h/t Nick Orr]
What else could this affect?
If you use any server-side plugins or helper applications, they may be vulnerable. You should contact your plugin vendor to confirm.
To determine if your server has any packages running Log4j, this Powershell script can scan your filesystem for the relevant traces inside JAR manifest files (Windows only). [h/t Koen Van Hulle]
MonkeyBreadSoftware has issued a post about the MBS Plugin and Log4j confirming that it is not vulnerable; but if you use MBS to load a JAR file, you should confirm that the JAR file you’re loading is not vulnerable.
In this FileMaker Forums post about 360works and Log4j, 360works has confirmed that Log4j is not used in virtually any of their products, except for 360works Plastic which received an update on December 11th. If you use 360works Plastic, you should update as soon as possible.
Zabbix, a monitoring system used by many FileMaker Server adminstrators, has confirmed that their products are not affected in this announcement about Zabbix and Log4Shell.
How do I fix it?
Claris has confirmed that FileMaker Server 18 and 19 are not vulnerable to any Log4j exploits, as they do not include that package. The best fix is to update to the latest version of FileMaker Server 19.
Below are the best-guess strategies that the community has come up with to fix the Log4Shell exploit on FileMaker server. The most-preferred mitigations are towards the top of the list.
Any one of these steps theoretically protects against Log4Shell, so you don’t need to implement every one of them. However, they shouldn’t interfere with each other if you want to take a belt-and-suspenders approach.
- Per Claris’s announcement, the best long-term solution is to update to the latest version of FileMaker Server 19, which is not susceptible to Log4Shell or any other Log4j-based exploit.
- FileMaker Server versions 10–17 use Log4j 1.x, which is not exploitable by Log4Shell but is susceptible to other Remote Code Execution vulnerabilities. For temporary mitigation, disabling the web publishing engine should prevent FileMaker Server from executing any Java calls. (In FileMaker 16 and earlier, you also need to disable the admin server/admin console using
fmsadmin stop adminserverin a terminal shell.) You should still upgrade to FileMaker 19 as soon as possible. - If you’re on FileMaker Server 10–17 and can’t turn off the Java-based components, make sure you’re running at least Java 6 update 212, Java 7 update 201, Java 8 update 192, or Java 11.0.2 (depending on which Java JRE your version of FileMaker Server uses). Ideally, you should install the latest Java version that is available for your FileMaker Server even if you are already running one of the older updates listed above. See Installing Java in FileMaker Server from Claris. This is not a permanent fix, it is only a partial mitigation.
- Although not officially recommended by Apache or Claris, some community members on FileMaker Server 17 have successfully replaced Log4j 1.2.x with the backwards-compatible API and core packages from Log4j 2.16. This will patch the vulnerability temporarily, but you should still prioritize upgrading to FileMaker 19 unless Claris clears FileMaker 17 and earlier. [h/t Jay Good]
- If you are familiar with Java programming and think you may have a vulnerable Java app on your server, you can try removing the JNDI lookup class from the classpath with a command like
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. (See https://logging.apache.org/log4j/2.x/security.html for more information.) This may be useful if you have Log4j installed from some other application, but this step should not be needed for FileMaker Server.
More Information
For more detailed information and mitigation steps that go beyond the scope of FileMaker Server and this blog post, we recommend this Log4Shell Detection & Mitigation Guide from LunaSec.
There is an active discussion about the Log4j exploit in the Claris Community FileMaker Forum, which may have more current information.
Claris has also made an official statement regarding Log4j and FileMaker products, excerpted below:
Claris International Inc. has confirmed that Claris FileMaker Server 18 and 19, Claris FileMaker Pro, and Claris FileMaker Cloud are not impacted by the Log4J2 zero-day vulnerability and no further action is needed.
The Log4j vulnerability affects package versions from 2.0 to 2.14. FileMaker Server 16 and 17 use an earlier version of Apache Log4j that is not impacted.
If you are running FileMaker Server 18 or earlier it is recommended that you upgrade to a supported version of the software.
NOTE: The vulnerability enables an attacker to execute arbitrary code loaded from LDAP servers. JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector.
Corrections? Questions?
Please Contact Us at Anchor-Buoy Software and we will update this post.
Thanks & Credits
This post is just a summary of the hard work carried out by many members of the FileMaker community. In particular, thanks to:
- Atsushi Matsuo [Emic Corporation]
- Chris Irvine [threeprong]
- Christian Schmitz [MonkeyBread Software]
- Jay Good [Community Member]
- Jesse Barnum [360works]
- Koen Van Hulle [Lesterius]
- Masayuki Nii [msyk.net]
- Nick Ciske [LuminFire]
- Nick Orr [Goya]
Thanks also to any community members I may have missed above — please let me know if you’re one of them so I can add you to the list.
About Anchor-Buoy Software
Anchor-Buoy Software, a Claris Partner, is a custom software consultancy based in Portland, Maine. We help businesses who need mobile, desktop, or web applications, as well as providing development services & technical advising for FileMaker teams that need supplemental expertise.
