Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

Updated , First Published by Pete Freitag

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 5.3.9.133 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:

A few additional mitigations that you can consider:

Adobe ColdFusion

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.

Lucee

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:

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 spreadsheet-cfml@3.1.0if 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 JMSAppender or 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.

Related Posts

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.

Comments

Ben Nadel

Thanks for putting this together, Pete! This is such crazy stuff!

Matthew Clemente

Hey Pete, thanks so much for this. Any thoughts on this older CVE that does appear to impact Lucee? https://www.cvedetails.com/cve/CVE-2019-17571/ Thanks!

Nik Y

Would this apply to CF on Linux and Windows? Where do you find the current version of log4j being used? Thanks for this info!

Pete Freitag

You're welcome @Ben it is crazy!! @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.

Matthew Clemente

Pete, you are the greatest. I really appreciate the time and insight you're sharing with everyone on this. Many thanks!

Miguel-F

Thanks for the information Pete!

Tim

Any thoughts on people still using CF 9 and earlier? seems like we are using ColdFusion9/runtime/../lib/log4j-1.2.15.jar scary times

eric belair

hi pete, 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? thanks, eric

Richard

Thanks! 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.

Raffaele

Has anybody been able to reproduce a POC of this issue on Coldfusion?

Mohammed

Pete, thank you for pulling this together, it’s most helpful. FYI, I noticed yesterday that LunaSec’s recommendation to modify message patterns, %m{nolookups}, has been redacted as bad practice and is no longer a recommended mitigation.

Pete Freitag

@Eric - I don't think it is possible to update log4j 1.x libraries to 2.x simply by replacing the jar file, but I haven't tested this out yet. Otherwise see the section on log4j 1.x in my entry.

Chris

Adobe has officially released mitigation steps for each version of ColdFusion. This until if/when they release a patch themselves. https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html

pmascari

Thanks, Pete. Love your services! 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.

Pete Freitag

@chris - thanks I updated the blog entry already @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.

chris

@Eric @Pete 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.

CN

Hi Pete, 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.

Pete Freitag

@CN - since you last blinked there is yet another wrinkle, you'll want to use 2.16.0 now instead of 2.15.0, there is a DOS issue. 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.

CN

@Pete - But of course, we had to throw more gasoline on the fire. Again, many thanks on the continued coverage of this whole thing.

James Weishaar

Thank you for providing this examination of the problem/solution. I appreciate it.

Tim Fitzpatrick

Adobe did (finally) address this: https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html

Jeff

Hi Pete, thanks for the great info. Once we are patched (setting in place and 2.16 jars in my case), is there a way to determine if a server had been previously compromised?

Pete Freitag

@Tim - thanks, I added the link to their KB article to this blog entry yesterday. @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

Jim

Can this be mitigated by using application firewall (WebKnight) to block multiple : or $ or {}?

Pete Freitag

@Jim - depends how good your pattern is. The general consensus seems to be that it is very hard to protect 100% using patterns, but you may be able to get close. It certainly doesn't hurt as an extra layer of defense though, so go for it, but don't only rely on a WAF. I am actually working on a filter for FuseGuard that should be ready soon.

Nicole SMith

@Pete Freitag this is very exciting news please keep us up to date on the FuseGuard filter.

Peter

There is a minor update on the Adobe patches. If you applied the QOQ one-off hot fixes, they will have to be reapplied, hf201800-4212383 and hf202100-4212383.

Mike K

I just applied update 3 for CF 2021 to my dev box and the query of queries hotfix after update 2 stopped working. I had to re-copy the hotfix jar file and restart the server.

Dave Cordes

Hey Pete, Where are those hotfixes located for the QoQ issue?

Peter

Email Adobe support at cfsup@adobe.com for the QOQ patches.

Michael

FYI: I have successfully started my development ACF2018 server under CommandBox by converting log4j.properties to log4j.xml using: 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).

David

Hi Pete, 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?

Sven

Hi Pete, 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!

John

I've noticed that recently scans are showing 'cf-logging.jar' as containing log4j version 1.2.15, and removing this jar appears to break the entire CF application. 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. Thanks!

Charlie Arehart

Hey, John, do your last comment, I will note that someone else finally brought it up as a tracker ticket. I have shared an extended comment there which may help you if you're still having to deal with the issue. There's no solution, but info (including more from Pete that I point to) which may at least give people the proper understanding of the situation (and why it may not likely change for some time, if at all). See: https://tracker.adobe.com/#/view/CF-4213568 I'm certainly open to feedback, there or here, from Pete or anyone. As always, I'm just trying to help.

Peter Asher

A further follow up on the QOQ problem. The fix hf202100-4212383 works for most queries. However, we found a problem with the order by statement, if we use the numeric value of the field, it fails. 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

Michael Miller

Hey Pete, Does CF 2021 Update 5 removes the remaining log4j 1.x? We are still getting Nessus critical hits...