Pete Freitag Pete Freitag

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

Updated on May 11, 2022
By Pete Freitag
coldfusionjava

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:

  • 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.class class 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

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:

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

  • log4j.properties
  • logger.xml
  • logging.properties

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.



coldfusion lucee java security log4j

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:

Fixinator

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.


Try Fixinator

CFBreak
The weekly newsletter for the CFML Community


Comments

Thanks for putting this together, Pete! This is such crazy stuff!
by Ben Nadel on 12/13/2021 at 1:58:09 PM UTC
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!
by Matthew Clemente on 12/13/2021 at 2:37:47 PM UTC
Would this apply to CF on Linux and Windows? Where do you find the current version of log4j being used? Thanks for this info!
by Nik Y on 12/13/2021 at 2:45:26 PM UTC
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.
by Pete Freitag on 12/13/2021 at 2:54:47 PM UTC
Pete, you are the greatest. I really appreciate the time and insight you're sharing with everyone on this. Many thanks!
by Matthew Clemente on 12/13/2021 at 2:56:36 PM UTC
Thanks for the information Pete!
by Miguel-F on 12/13/2021 at 4:17:03 PM UTC
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
by Tim on 12/13/2021 at 5:13:33 PM UTC
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
by eric belair on 12/13/2021 at 5:38:30 PM UTC
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.
by Richard on 12/13/2021 at 7:09:11 PM UTC
Has anybody been able to reproduce a POC of this issue on Coldfusion?
by Raffaele on 12/14/2021 at 10:24:09 AM UTC
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.
by Mohammed on 12/14/2021 at 1:02:43 PM UTC
@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.
by Pete Freitag on 12/14/2021 at 2:59:09 PM UTC
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
by Chris on 12/14/2021 at 5:23:40 PM UTC
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.
by pmascari on 12/14/2021 at 5:33:50 PM UTC
@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.
by Pete Freitag on 12/14/2021 at 5:48:58 PM UTC
@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.
by chris on 12/14/2021 at 6:00:19 PM UTC
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.
by CN on 12/14/2021 at 8:27:41 PM UTC
@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.
by Pete Freitag on 12/14/2021 at 8:46:15 PM UTC
@Pete - But of course, we had to throw more gasoline on the fire. Again, many thanks on the continued coverage of this whole thing.
by CN on 12/14/2021 at 9:08:23 PM UTC
Thank you for providing this examination of the problem/solution. I appreciate it.
by James Weishaar on 12/14/2021 at 9:46:29 PM UTC
Adobe did (finally) address this:
https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html
by Tim Fitzpatrick on 12/15/2021 at 3:44:44 PM UTC
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?
by Jeff on 12/15/2021 at 5:21:51 PM UTC
@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
by Pete Freitag on 12/15/2021 at 5:32:09 PM UTC
Can this be mitigated by using application firewall (WebKnight) to block multiple : or $ or {}?
by Jim on 12/15/2021 at 6:49:56 PM UTC
@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.
by Pete Freitag on 12/15/2021 at 7:02:20 PM UTC
@Pete Freitag this is very exciting news please keep us up to date on the FuseGuard filter.
by Nicole SMith on 12/16/2021 at 1:27:20 AM UTC
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.
by Peter on 12/20/2021 at 6:42:42 PM UTC
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.
by Mike K on 12/20/2021 at 6:45:51 PM UTC
Hey Pete,

Where are those hotfixes located for the QoQ issue?
by Dave Cordes on 12/21/2021 at 12:11:11 AM UTC
Email Adobe support at cfsup@adobe.com for the QOQ patches.
by Peter on 12/21/2021 at 5:22:28 PM UTC
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).
by Michael on 12/30/2021 at 11:36:22 PM UTC
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?
by David on 01/13/2022 at 3:26:40 AM UTC
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!
by Sven on 01/17/2022 at 2:20:30 PM UTC
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!
by John on 02/09/2022 at 8:49:04 PM UTC
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.
by Charlie Arehart on 06/16/2022 at 11:06:07 PM UTC
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
by Peter Asher on 08/19/2022 at 5:57:05 PM UTC
Hey Pete, Does CF 2021 Update 5 removes the remaining log4j 1.x? We are still getting Nessus critical hits...
by Michael Miller on 10/12/2022 at 11:17:59 AM UTC