Can I get any insight into which version of Lucee (if any) are impacted by the log4j vulnerability? Remote code injection in Log4j · CVE-2021-44228 · GitHub Advisory Database · GitHub
Thanks!
2 Likes
I’d want someone from LAS to confirm, but based on
# find / -iname '*.jar' | grep -v www|grep -i log
/opt/lucee/server/lucee-server/bundles/org.lucee.commons.logging.adapters-1.1.0.jar
/opt/lucee/server/lucee-server/bundles/log4j-1.2.17.jar
/opt/lucee/server/lucee-server/bundles/log4j-1.2.16.jar
/opt/lucee/server/lucee-server/bundles/org.lucee.commons.logging-1.2.0.jar
/opt/lucee/server/lucee-server/bundles/org.lucee.commons.logging-1.1.1.L0001.jar
/opt/lucee/server/lucee-server/bundles/org.lucee.commons.logging.api-1.1.0.jar
The log4j shipped (at least in the Docker versions of 5.3.x) is v1.x that isn’t vulnerable according to Log4Shell: RCE 0-day exploit found in log4j, a popular Java logging package | LunaTrace
2 Likes
There’s some discussion that 1.x might be vulnerable in a similar way, but the maintainers say it’s well out of support and has other vulns too and nobody should be running it!
Someone at LAS might have a busy time then, because upstream Tomcat doesn’t require log4j : Apache Tomcat 9 (9.0.73) - Logging in Tomcat
Glad to see this is already being discussed; I was just about to start a thread on the matter (this VULN just came across my desk).
FWIW, according to cloudflare’s blog post on this zero day, it does not affect those on Java 8 update 121 (1.8.0_122) and up, which is from Jan 2017. That implies it would not affect Java 9 (released in Sep 2017) and above.
If this is true, many may be able to breathe a sigh of relief. But let’s see if that news is corroborated/elaborated/pans out.
(For those seeing this who may run ACF, the installers for cf2018 and 2021 implement Java 11 out of the box, but for the very first cf2018 installer that implemented Java 10. And cf2016 has been able to run Java 11 since it’s update 8, as detailed in my table of Java version support for ACF. )
I don’t see any mention of Java versions in that blog post.
My reading of the log4j pages about the vulnerability is that log4j 1.x has several unpatched issues and cannot be made secure at this point – only migrating to log4j 2.x solves this, either by using 2.15.0 or by disabling message lookup (on some earlier versions of 2.x).
The java version Charlie is referring to only protects you from one one possible attack vector, JNDI LDAP, but there are other attack vectors possible from my understanding.
Looks like CloudFlare must have removed it from their blog entry once they realized the mistake.
Pete Freitag
Foundeo Inc.
2 Likes
Yep, and thanks, Pete. Glad I worded things as I did, saying that we’d have to see how that assertion of theirs panned out.
Bummer to see them just remove it rather than strike it out, with a brief explanation. (And thanks for the updates you’ve shared to Hackmycf customers.)
1 Like
Just joining on this one. We are looking for confirmation that this is not an issue in Lucee standard install as well.
To anyone using the Spreadsheet CFML library (formerly Lucee Spreadsheet) version 3.1.0, there’s a new 3.2.0 release which replaces the vulnerable log4j jar with the 2.15.0 patch. Log4j was only introduced in the 3.1.0 release (via POI 5.1.0) so if you hadn’t upgraded to that version it’s not urgent.
4 Likes
Yea I thought we would be safe initially, but Lucee does use log4j. This is also an interesting article:
I added “-Dlog4j2.formatMsgNoLookups=true” in the lucee options just to be sure.
I’m getting lots of questions about log4j v1.2.17 being bundled into Lucee (we have v5.2.8.189 in production) and whether this presents a vulnerability. The criteria apparently being whether there is an ‘appender’ using JDNI present.
And the follow-up question being, is a version of Lucee planned with log4j v2.15?
Cheers,
B)
1 Like
So grateful for this Zackster! Thank you!
1 Like
I’m grateful for that too - but how do I explain that to people looking at the jar files in Lucee and see Apache Log4j 1.2 loaded and active?
sorry - I see the comment from Zacster is actually link. Thank you!
1 Like
Yeah - Zackster addressed that at the bottom.
what file did you add that line in?
@DrunkenMoose I second @kevco’s question, where did you make the change for Lucee?
I was looking around C:\lucee\jre\bin and C:\lucee\jre\conf directories, but not seeing it there.
EDIT: I found C:\lucee\jre\lib\jvm.cfg which is possibly what we’re looking for, although a default install only seems to have “-server KNOWN -client KNOWN” entries, but the syntax with the leading -'s appears correct. Can anyone confirm?
For some of our ACF 10 servers, adding the “-Dlog4j2.formatMsgNoLookups=true” was easy under ACF Admin Panel > Settings > Java and JVM, had a text field to paste config options there, but not finding similar in Lucee.
Note that according to lucasec,
the ‘formatMsgNoLookups’ property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the ‘formatMsgNoLookups=true’ mitigation strategy is available in version 2.10.0 and higher
source: https://www.lunasec.io/docs/blog/log4j-zero-day/
I’m on lucee 5.3.8.206 and it sadly comes with log4j 1.2.17 . This setting has no effect.