The new security vulnerability Log4j is 10/10 on the “Hacking Richter scale”. How might it be affecting your ColdFusion servers? And what can you do to protect your company?
TLDR;
- This issue affects most servers as Log4j is used by many software tools on modern servers, as well some versions of Adobe ColdFusion. Lucee CFML is not affected.
- Action: Apply the latest Adobe hotfixes to CF 2018 and CF 2021 (see below for links)
- Patch Log4j in all your server software (not just in older versions of CF)
- Optional: Add the JVM arg -Dlog4j2.formatMsgNoLookups=true to the java.args line in your jvm.config file (may need to update CF first depending on version – details below).
Understanding the Log4j Vulnerability
The log4j (CVE-2021-44228) vulnerability is extremely bad. Millions of applications use Log4j for logging, and all the attacker needs to do is get the app to log a special string.
Already many servers have been hit with this Day Zero Attack that was first discovered Friday 12/10/21. Including Apple, Twitter, Steam, Tesla.
So what about your ColdFusion servers?
I am glad to say that both Adobe ColdFusion engineering team and the Lucee teams responded very fast to this issue.
The Adobe team worked over the weekend to review how this exploit affects a vanilla CF2021 and CF2018 install. And have released hotfixed for them. See below for full details and what to do.
The Lucee team reported that it is not affected by this issue. Details below. Good news for open source CFers!
CF security expert Pete Freitag says “Some versions of ColdFusion (for example early versions of ColdFusion 2018) might include a version of log4j before 2.10.0 and greater than 2.0 which means that JVM arg mitigation doesn't work, so you would need to update to the latest version first.
Non-CF software
Here is what to do for Apache and other non-CF software that you have on your server
- Search for all Log4j use on your server eg Apache.
- Patch log4j for each of the instances found.
- If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
FYI Apache has issued four Log4j patches so far – currently on version 2.17
Learn about the 7 Steps To Get The Best Coldfusion Web Application Performance
Update: Adobe hotfixes released
Adobe released an hotfixes on 12/17/21 to ColdFusion 2021, and 2018 to address the critical CVE-2021-44228 and CVE-2021-45046. These replace the manual fix steps below.
Adobe ColdFusion 2021 Update 3:
https://helpx.adobe.com/
Adobe ColdFusion 2018 Update 13:
https://helpx.adobe.com/
Additional Messaging From Adobe:
“This is purely security update, so any fix that you have applied ex QoQ needs to be applied again manually. Also, even if you have followed the mitigation steps and updated the jars to 2.16, please apply the update.”
API Manager / Performance Monitoring Toolset:
https://helpx.adobe.com/
https://helpx.adobe.com/
https://helpx.adobe.com/
Adobe detailed guidance to fix Log4j vulnerability in CF
If for some weird reason you can not apply those hotfixes above, or you have older versions of CF, here are manual steps to address the Log4j issue from this earlier Adobe article.
ColdFusion (2021 release)
ColdFusion 2021 ships with Log4j versions 2.13.3 and 1.2. The former is impacted by this vulnerability, while the latter is not.
- Stop the server.
- Navigate to the directory <cf_root>\<Instance_name>\bin.
- Open jvm.config file and add -Dlog4j2.formatMsgNoLookups=true argument in java.args section. Save the file.
- If using any third-party libraries that use Log4j2, and hence vulnerable, search for log4j-core in <cf_root> directory. If the Log4j2 version (<= 2.10 and >=2.0-beta9) is found, remove the JndiLookup class from the classpath like below, otherwise skip this step.
- If the Operating System is Windows , then unzip the log4j-core-2.x.jar file and remove the class from path: org/apache/logging/log4j/core/lookup/JndiLookup.class and zip the log4j-core-2.x.jar. X is the version number you found in the folder.
- If the Operating System is non-windows, then remove the JndiLookup class from the classpath : “zip -q -d log4j-core-2.x.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”. X is the version number you found in the folder.
- Restart the instance.
- Repeat the procedure for all other instances.
ColdFusion (2018 release)
ColdFusion 2018 ships with log4j 2.13.3 and/or 2.9.0, and log4j 1.2. The former is impacted by this vulnerability, while the latter (that is, v1.2) is not impacted.
- Stop the server.
- Navigate to the directory <cf_root>\<Instance_name>\bin.
- Open jvm.config file and add -Dlog4j2.formatMsgNoLookups=true argument in java.args section. Save the file.
- Copy the patched log4j-core-2.9.0.jar file with JNDILookUp class that you have removed. The new file can be downloaded from here. If you find log4j-core-2.9.0.jar, move the file to a temporary location. If not found, skip this step.
The temporary location must be outside ColdFusion's classpath. - If you are using any third-party libraries that use log4j2, and hence vulnerable, search for log4j-core in <cf_root> directory. If log4j2 version (<= 2.10 and >=2.0-beta9) is found, remove the JndiLookup class from the classpath as mentioned below, otherwise skip this step:
- If the Operating System is Windows, then unzip the log4j-core-2.x.jar file and remove the class from path : org/apache/logging/log4j/core/lookup/JndiLookup.class and zip the log4j-core-2.x.jar. X is the version number that you found in the folder.
- If the Operating Systems is non-Windows, then remove the JndiLookup class from the classpath : “zip -q -d log4j-core-2.x.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”. X is the version number that you found in the folder.
- Restart the instance and delete log4j-core-2.9.0.jar from the temporary location.
- Repeat the procedure for all other instances.
ColdFusion (2016 release)
ColdFusion (2016 release) ships with Log4j 1.2, which is not impacted. If the installation has any third-party libraries that use Log4j2, follow the steps listed for third party libraries above for version 2018 or 2021.
Performance Monitoring Toolset 2021
Performance Monitoring Toolset 2021 ships with log4j 2.11.1 and log4j 2.3. Both versions are impacted.
- Stop the Performance Monitoring Toolset and datastore services.
- Navigate to the directory <PMT_Home>\datastore\config.
- Open the file jvm.options, add -Dlog4j2.formatMsgNoLookups=true argument in #log4j2 section. Save the file.
- Navigate to the directory <PMT_Home>\lib.
- Move the file log4j-core-2.3.jar to a temporary location.
- Copy the patched log4j-core-2.3.jar file with JNDILookUp class removed. The file can be downloaded from here.
- Restart the Performance Monitoring Toolset and datastore services.
Delete log4j-core-2.3.jar from the temporary location.
Performance Monitoring Toolset 2018
Performance Monitoring Toolset 2018 ships with log4j 2.9.1 and log4j 2.3. Both versions are impacted.
- Stop the Performance Monitoring Toolset and datastore services.
- Navigate to the directory <PMT_Home>\datastore\lib.
- Move the file log4j-core-2.9.1.jar to a temporary location.
- Copy the patched log4j-core-2.9.1.jar file with JNDILookUp class removed. The file can be downloaded from here.
- Navigate to the directory <PMT_Home>\lib.
- Copy the file log4j-core-2.3.jar to a temporary location.
- Copy the patched log4j-core-2.3.jar file with JNDILookUp class removed. The file can be downloaded from here.
- Restart the Performance Monitoring Toolset and datastore services.
Delete log4j-core-2.3.jar and log4j-core-2.9.1.jar from the temporary location.
API Manager 2021, 2018, and 2016
API Manager 2021, 2018, and 2016 ship with log4j 2.3. This version is impacted.
- Stop the API Manager server (<APIM_Home>\bin) and Analytics (<APIM_Home>database\analytics\bin) service.
- Navigate to the directory <APIM_Home>\lib.
- Move the file log4j-core-2.3.jar to a temporary location.
- Copy the patched log4j-core-2.3.jar file with JNDILookUp class removed. The file can be downloaded from here.
- Restart the Analytics service and the API Manager server.
You can now delete log4j-core-2.3.jar from the temporary location.
Lucee CFML is not affected
Lucee CFML ships with log4j 1.2.x which is not listed as an affected version for CVE-2021-44228. Good news for open source CFers!
More on what the Lucee team had to say about Log4j.
Once again we see why regular CF updates are important
Log4j did not affect the latest patched versions of CF 2021 or CF 2018. A reminder why it is so important to apply hotfixes regularly. And why you should update to the latest version of ColdFusion regularly!
Here at TeraTech, we use Pete Freitag’s HackMyCF tool to monitor CF servers for old version and other security issues. He also sends out CF security alerts to customers, which is how I first learned of this vulnerability.
Here is Pete's article on Log4j and CF
Why the Log4j Attack Is Critical
The problem is that “log4j” package is so ubiquitous — it is used with Apache software like Apache Struts, Solr, Druid, along with other technologies Redis, ElasticSearch, and even video games like Minecraft.
Other services affected include:
-
AWS
-
AZURE
-
Broadcom
-
Cisco
-
CPanel
-
ConnectWise
-
Debian
-
Eclipse
-
Elastic
-
F-Secure
-
GitHub
-
Huawei
-
Jenkins
-
JFROG
-
Jitsi
-
Kafka
-
McAfee
-
Solarwinds
-
Netflix
-
Oracle
-
Palo-Alto
-
Pulse Secure
-
RedHat
-
RSA
-
Sophos
-
SonicWall
-
VMware
How are you reacting to this major security issue?
More Log4j Updates
News: Foundeo released an update to FuseGuard
Foundeo has released an update to FuseGuard (version 3.4.0). It includes a new Log4ShellFilter created to block these CVE-2021-44228 exploit attempts. It also updates the CFLogLogger to add additional escaping.
Fixinator 2.0.4 Enterprise Server has been released, which adds detection of some known log4j 2.15 jars, as well as some vulnerable CFML packages (scans box.json). Fixinator Cloud Scanning server has already been updated to detect these things. (NOTE: this is for those of you who are not using the Enterprise edition locally)
FuseGuard and Log4j and cflog
FuseGuard does not include any log4j jar files, however it does include a CFLogLogger, which passes log messages to the cflog tag. As such we strongly recommend that you apply any mitigations your CFML server vendor recommends. To date Adobe has published a KB article here, and plans to release a patch on 2021-12-17. More info on the issue here.
Even though Adobe has not stated whether or not cflog is vulnerable, we have updated the CFLogLogger in version 2.4.0 to escape $ as __DOLLAR_SIGN__. Special characters were already escaped in the log message and detail by default, and the CFLogLogger is not enabled by default.
If you have the CFLogLogger enabled (most configurations will have this disabled by default) we recommend updating to FuseGuard 3.4.0, or add this mitigation above the cflog tag in the CFLogLogger:
<cfset text = Replace(text, "$", "__DOLLAR_SIGN__", "ALL")>
New Log4j DOS issue found
Another CVE for log4j was published today CVE-2021-45105, and log4j 2.17.0 was released to address it.
The patch to Adobe ColdFusion (CF2021u3, and CF2018u13) updated log4j to version 2.16.0, so it does not include this latest version yet.
We'll let you know once we here any official guidance from Adobe on this.
The issue doesn't look like it is as severe original issue. It looks like a denial of service (DOS) issue in certain configurations.
Details From: https://logging.apache.org/log4j/2.x/security.html
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.
Mitigation
Log4j 1.x mitigation
Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation
Implement one of the following mitigation techniques:
Java 8 (or later) users should upgrade to release 2.17.0.
Alternatively, this can be mitigated in configuration:
In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.
Work in progress
The Log4j team will continue to actively update this page as more information becomes known.
This log4j (CVE-2021-44228) vulnerability is extremely bad. Millions of applications use Log4j for logging, and all the attacker needs to do is get the app to log a special string. So far iCloud, Steam, and Minecraft have all been confirmed vulnerable.
— Marcus Hutchins (@MalwareTechBlog) December 10, 2021
- Statement on Log4j security issue by Govt security unit CISA
- Thoughtful article on Log4j and how backwards compatibility on this library might have helped create the issue by David Crawshaw
- General article for the layman on Log4j
- Source for Adobe quote by Mark Takata on Log4j and extensive discussion of the issue by Charlie Arehart, Dave Watts and Adobe staff
- About the log4jshell pandemic, and what CF folks can do about it
Michaela Light is the host of the CF Alive Podcast and has interviewed more than 100 ColdFusion experts. In each interview, she asks "What Would It Take to make CF more alive this year?" The answers still inspire her to continue to write and interview new speakers.
Michaela has been programming in ColdFusion for more than 20 years. She founded TeraTech in 1989. The company specializes in ColdFusion application development, security and optimization. She has also founded the CFUnited Conference and runs the annual State of the CF Union Survey.
