Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee
There is a critical security vulnerability (CVE-2021-44228 aka Log4Shell) in the java library log4j which is a popular logging library for java applications. It is included in both Adobe ColdFusion and Lucee for example.
Putting together some info to help sort this issue out as it pertains to ColdFusion and Lucee users. I'll update this entry as needed.
TLDR: Adobe ColdFusion users should upgrade to either ColdFusion 2018 update 14 or ColdFusion 2021 Update 4 (both now use log4j version 2.17.2). Lucee has released version 220.127.116.11 with Log4j 2.17.2, earlier versions used log4j 1.x.
What versions of log4j are vulnerable to CVE-2021-44228?
According to the Log4j Security Page:
Versions Affected: all versions from 2.0-beta9 to 2.14.1. Fixed in Log4j 2.15.0.
Here's the jira issue for when the JNDI lookup feature was added in 2.0-beta9: LOG4J2-313
Another CVE: CVE-2021-45046 (2021-12-14)
It appears that the fix in 2.15.0 and the JVM mitigation was incomplete. Version 2.16.0 was released.
CVE-2021-45046 Upgraded to Critical (2021-12-17)
Another issue was found in 2.15.0, a more serious / critical RCE. Fixed in 2.16.0
Another CVE: CVE-2021-45105 (2021-12-17)
A Denial of Service (DOS) issue in 2.16.0 and below, fixed in 2.17.0
Another CVE: CVE-2021-44832 (2021-12-28)
Log4j versions 2.17.0 and below are vulnerable to a RCE when the attacker can modify the log4j configuration. 2.17.1 was released to address this issue.
How can I mitigate this issue?
Here's a list of possible mitigations, initially sourced from LunaSec's blog:
- Update your log4j jars to latest patched version of Log4j 2:
2.15.0(see CVE-2021-45046) 2.16.0(see CVE-2021-45105) 2.17.0(see CVE-2021-44832) 2.17.1
- Add JVM arg:
-Dlog4j2.formatMsgNoLookups=true(only works on log4j 2.10.0 and up). Incomplete fix, still has DOS see above: CVE-2021-45046, CVE-2021-45105, CVE-2021-44832
- According to Microsoft's Response to this issue, you can set an environment variable instead of the JVM argument:
LOG4J_FORMAT_MSG_NO_LOOKUPS=true- incomplete for CVE-2021-45046, CVE-2021-45105, CVE-2021-44832
- All of the above require restarting the java process (restart ColdFusion or Lucee).
A few additional mitigations that you can consider:
- Use your network firewall to ensure that no egress internet traffic leaves the server. This might be tricky depending on your requirements, but if the server cannot make a network request to the internet, this has a big impact on the severity of this. This could also be done at the jvm level using a java security policy or sandbox security in ColdFusion. You may still have DOS issues to consider with this approach.
- If you cannot use the jvm arg because you have log4j2 2.0 - 2.10.0 and for some reason cannot update to version 2.17.0 then it should be safe remove the offending
JndiLookup.classclass file from the jar. Details. You may still be vulnerable to CVE-2021-45046, CVE-2021-45105.
- Many Web Application Firewalls (WAF) provide detection / blocking of Log4Shell attack patterns. However you should never treat a WAF as a 100% solution. Many if not all WAF patterns could be evaded, but they can still block many attempts (defense in depth). FuseGuard a WAF written in CFML has added a Log4ShellFilter in version 3.4.0
Adobe ColdFusion 2018 and 2021 include potentially vulnerable versions of log4j2. I notified the Adobe Product Security Incident Response Team (PSIRT) early Friday (2021-12-10) morning of the issue. Adobe has published a KB article on 2021-12-14, and on 2021-12-17 released ColdFusion 2021 Update 3, and ColdFusion 2018 Update 13 to address CVE-2021-44228 and CVE-2021-45046 by updating log4j to version 2.16.0.
To address CVE-2021-45105 and CVE-2021-44832 apply ColdFusion 2018 update 14 or ColdFusion 2021 Update 4 (which updates log4j version to 2.17.2). Previous advice from Adobe is no longer relevant after update 4/14
KB article 1, KB Article 2
Some versions early versions of ColdFusion 2018 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.
My suggestion for people using ColdFusion would be to update to the latest patched version of ColdFusion, and then add the JVM arg
-Dlog4j2.formatMsgNoLookups=true to the
java.args line in your
jvm.config file. Then if you are on CF2018/2021 follow their KB article to update log4j to version 2.17.0 (or 2.17.1)
Update 2022-05-10 Adobe released ColdFusion 2021 update 4, ColdFusion 2018 update 14 which update log4j version to 2.17.2
Update 2021-12-17 Since Adobe has released an update for 2018, and 2021 which bring the log4j version to 2.16.0, I still don't think it is a bad idea to add the JVM mitigation, incase there are any third party libraries on your server now or in the future.
ColdFusion 2016, update 17 appears to ship with log4j-1.2.17, see info below about log4j 1.x versions.
Discussion about this issue can be found on Adobe Forums.
From what I have seen, lucee ships with log4j 1.2.x which is not listed as an affected version for CVE-2021-44228. See more details about log4j 1.x below.
The Lucee team has posted a message stating: Lucee is not affected by the Log4j JNDI exploit.
Where else should I look?
You might have a third party library that uses log4j as a dependency. Here's a list of some examples:
- spreadsheet-cfml - version 3.1.0 included log4j-api-2.14.1.jar, version 3.2.1 has been released which includes log4j-api-2.16.0.jar. Version 3.2.0 included log4j-api-2.15.0.jar
It is a good idea to scan your server hard drive for files with log4j in the name, for example on linux servers you can run this:
find / | fgrep log4j
Fixinator has been updated to scan for vulnerable log4j jars, and also flags
[email protected]if installed or listed as a dependency in your box.json. Fixinator does not do a deep scan within jars at this time. Some have found this tool handy for scanning jars: Log4JShell-Bytecode-Detector.
CISA has created a log4j affected products db which you can check.
Are only certain versions of Java Vulnerable?
There is a lot of confusion around this point. My understanding is that the version of java might make some attack vectors (such as JNDI LDAP) safe by default, but not all attack vectors. So the possibility still exists in any version of java from my understanding.
Is log4j 1.x vulnerable to CVE-2021-44228?Again, it is not currently listed as an affected version, but it is also considered end of life, and they do not plan to fix any issues (including prior security issues already known). According to comments on here it appears that the JMSAppender in log4j 1.x may have a similar issue , however you'd need to have the JMSAppender enabled. You can check to make sure you are not using the JMSAppender to confirm.
Update: JMSAppender issue has been given identifier: CVE-2021-4104
Check log4j configuration to make sure you don't use
SocketAppender (CVE-2019-17571) such as:
I have published a ton more info specific to Log4j 1.2.x vulnerabilities.
Here's some java or CFML code you can call to check the log4j version at runtime.
DISCLAIMER: The content (and links) on this page are provided as is, without warranty of any kind. Use at your own risk. You should consult with your software vendors to ensure that you are properly protected.
Like this? Follow me ↯Tweet Follow @pfreitag
Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee was first published on December 10, 2021.
If you like reading about coldfusion, lucee, java, security, or log4j then you might also like:
- Spring4Shell and ColdFusion
- OpenSSL and ColdFusion / Lucee / Tomcat
- Log4j 1.x Vulnerability Mitigation Guide
- Log4Shell Vulnerability Timeline
- How to get Log4j Version at Runtime in Java
- Updating Java on ColdFusion or Lucee
- Scope Injection in CFML
- HashDOS and ColdFusion
The Fixinator Code Security Scanner for ColdFusion & CFML is an easy to use security tool that every CF developer can use. It can also easily integrate into CI for automatic scanning on every commit.
The weekly newsletter for the CFML Community
Any thoughts on this older CVE that does appear to impact Lucee?
@Matthew - that's a good question, my understanding (and I could be wrong because I haven't spent adequate time investigating it), is that CVE-2019-17571 exists in the SocketServer, which you have to turn on and it has to be listening to untrusted traffic.
According to this post (https://stackoverflow.com/questions/11759196/log4j-how-to-use-socketappender), you'd start the server in another process like this:
java -classpath log4j.jar org.apache.log4j.net.SimpleSocketServer 4712 log4j-server.properties
Then use the SocketAppender to write logs to the server.
So based on that it doesn't look like something Lucee would be vulnerable to by default, but if you configured it to use the SocketAppender or the JMSAppender then you might have a concern.
seems like we are using ColdFusion9/runtime/../lib/log4j-1.2.15.jar
i'm primarily a developer but have been tasked with handling this issue by a client because the "ColdFusion" guy. we're running CF11 with Java 1.8.0_130. it seems to me that we should not be affected or, at least there's nothing we can really do here outside of a full CF upgrade. is it possible to update the existing Log4j 1.2.15 libraries used by CF to the new version (2.15.0) with the fix?
I'm primarily operations - but have what's probably a question with an obvious answer.
With respect to this - is there any difference in placing -Dlog4j2.formatMsgNoLookups=true in: 1) placing iot in CFadmin window under JVM Arguments, or, 2) in the actual JVM.config?
My understanding is that they are one and the same for this purpose - but wanted to make sure on this one.
Adobe's mitigation steps are mentioning only version 2.9.0 of this JAR file. Our CF servers look to be using 2.13.3.
Sorry, but I'm not clear if this affects us (CF2018) and if we should replace the file as Adobe suggests? Can you clarify?
We HAVE put in the JVM arguments.
@pmascari - version 2.13.3 is vulnerable, but the JVM argument does protect that version. So I don't think you want to use the patched log4j 2.9.0 file in that case. You can remove the JndiLookup.class from the 2.13.3 jar if you want though.
You most definitely can not just go from 1.x to 2.x (google it - the apache page mentions this).
@Eric - you might not be vulnerable to this but CF11 has not been patched in a long while and in particular there was a critical security flaw fixed in march but only back to CF2016 - if your CF11 server is on the internet it's only a matter of time (and it might already be) until it's compromised.
I highly suggest you update - which sucks because going from CF11 to CF2018/2021 is almost definitely going to break at least some code. We had issues just going from 2016 to 2018...
You should really update java too - that should be painless - just requires installing it and pointing CF to the new JVM path in the admin. There are definitely existing vulnerabilities in 8u130...quite a few.
On the forums there are lots of references to just swapping out the log4j libraries for the 2.15.0 updates.
Do you have any thoughts on this since Adobe didn't seem to reply to any of the questions surrounding that?
Thanks for all your hard work on this cavalcade of suck that surrounds this vulnerability.
I think Adobe will probably provide the update in their hotfix on the 17th, you can try doing it yourself before then, I think some have and found it worked ok on ColdFusion 2018 / ColdFusion 2021.
@Jeff - check the logs ;-) In all seriousness, that's a great question, and is outside of my area of expertise. I did see Microsoft has published some detection methods here: https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/ this page has a ton of info, take a look under "Detecting exploitation attempts" https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/#detection-testers
I am actually working on a filter for FuseGuard that should be ready soon.
Where are those hotfixes located for the QoQ issue?
java org.apache.log4j.config.Log4j1ConfigurationConverter --in=cfusion/lib/log4j.properties --out=cfusion/lib/log4j.xml --verbose
I then removed log4j.properties and replaced all Log4j JARs with log4j-core-2.17.1.jar, log4j-api-2.17.1.jar, and log4j-to-slf4j-2.17.1.jar. It seems be working fine so far.
This does not work with a standalone ACF2018 install(Unable to initialise Logging service: java.lang.NoClassDefFoundError: org/apache/log4j/Layout).
I have installed the CF2021 patch, and copied log4j 2.17.1 version files to C:\ColdFusion2021\cfusion\lib folder. However, I found that in C:\ColdFusion2021\cfusion\jetty\lib\ext there are old versions of log4j files, including log4j-1.2.17.jar and log4j-1.2.17.zip. Should/can I remove them as well?
I have just freshly installed CF2021 on a server and brought it to update 3. When I went to swap the Log4J 2.16 components for 2.17, I noticed that there is another log4j.jar there as well. This one contains version 1.2.15. Why does Adobe leave these old versions here in parallel (or a third one if you count the one in Jetty?) Did I miss a hint?
How do you handle these old versions?
Thanks a lot!
Do you know if there is a way to remove this old log4j safely, or update CF to stop using it? Even with the 2.17 log4j installed it seems to still rely heavily on this massively out of date version.
I'm certainly open to feedback, there or here, from Pete or anyone. As always, I'm just trying to help.
If we use the field name, it works.
Ie: if we have order by set to ‘5 DESC,fieldb,fieldc’ - it fails
If we have order by set to ‘fielda DESC, fieldb, fieldc’ - it works