Given that Log4j security vulnerabilities are being examined and exploited, does Lucee recommend anything with regard to this CVE: CVE-2019-17571 : Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be explo
Lucee OOTB doesn’t listen on a socket for logging data…
Thanks @Zackster! Just trying to cover all my bases. Really appreciate the clarification.
It’s worth noting that Log4J 1.x is EOL and known to be vulnerable to multiple RCE exploits. Using it as cover from Log4Shell is a pretty terrible strategy.
Further, the way I read it, this report indicates that ALL versions prior to 2.15 (which includes 1.x) are affected. Remote code injection in Log4j · CVE-2021-44228 · GitHub Advisory Database · GitHub
Any Log4J version prior to v2.15.0 is affected to this specific issue.
The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.15.0 where possible.
I can’t find any references to it at the moment but I feel like I’ve also seen some people using the java version as cover, and apparently that is also not good enough:
Not sure if this is a silly question – can we update the version of
Log4j that is currently shipped with our install of Lucee? Or, will that break other Lucee core code?
It does read that way, but I don’t think it can be right given that the JNDILookup functionality was only added in version 2.0-beta9 according to this admirably clear CloudFlare article.
Thanks for clearing that up. I don’t think it changes my point that we should not just relax knowing that 1.x is not vulnerable to log4shell. If anything, this event has shined a spotlight on log4j and now the frequency of attempts using known old exploits are likely to increase because of new awareness.
Just to make sure that it doesn’t get buried by these replies, I want to echo that I too would like to know the answer to @bennadel’s question:
can we update the version of
Log4jthat is currently shipped with our install of Lucee? Or, will that break other Lucee core code?
I’ve also read in this adobe thread, in which @carehart mentions, that ACF uses log4j for cflog/writelog, and that would probably limit the surface of attack in a certain way to those tags. Would that apply also to Lucee?
I know that is not a big relief for most of the admins, but for those who run their servers alone with their own code, wouldn’t it help to just not use those tags for now (until we can get the lib updated)?
I have a concern that we may be using 3rd-party Fat JARs that may have a problematic version of
log4j internally. A “fat jar” / “uber jar” is essentially (as I understand it) a JAR file that has all its dependencies baked into it. I’m trying to inspect some of the JAR files using:
jar tf /path/to/jar/file
Which gives me a massive manifest of entries. The problem is, I’m not really a “Java guy” and I don’t really know what I’m looking for. Has anyone thought to do something like this? Any tips on what I might keep my eye open for?
@bennadel This tool (recommended on Slack by Tom King) seems good and simple to use.
Thank you. I will look at how it works, and I will also pass on to my SEC team!
@Julian_Halliwell @bennadel That Logpresso scanner is nice. Requires VC Redist 14 x64. (Link to download that from MS here: Download Microsoft Visual C++ 2015 Redistributable Update 3 RC from Official Microsoft Download Center)
I ran this on our Lucee dev instance against c:\lucee, found 0 vulnerable – as expected, since it’s log4j1.2 and not the 2.9 > version > 2.15 vulnerable versions.
I’m looking at the Lucee Admin > Bundles (Jars) and see jog4j 1.2 is active and located C:\lucee\tomcat\lucee-server\bundles\log4j-1.2.17.jar
Wondering about manually upgrading this – how can I tell Lucee to use the 2.15 if I drop that JAR in that directory? Is there a specific Lucee config file to edit to load that jar instead, or in place of? Perhaps like the automated scanner, renaming the 2.15 version to match the expected filename, but I would rather not do that.
Anyone have an actual update process to share?
@bennadel There is also another tool here
which I have wrapped up inside a nice standalone CommandBox Task Runner which will download what it needs and scan any folder of jars recursively for vulnerable jars. (It scans the folder resursivley and then scans each jar it finds recursively as well)
Run the task like so in CommandBox. You can just point it to an entire server home if you like.
task run :scanPath="D:\path\to\jars"
Plus, if you run your Adobe ColdFusion or Lucee servers via CommandBox you can apply the JVM arg to mitigate against this vuln globally like so (For ACF servers, make sure you’re on the latest updater to ensure this JVM arg will get picked up. Lucee doesn’t bundle a version of Log4j new enough to use this JVM arg, so it would be if you had your own Log4j jars on the classpath.)
config set server.defaults.jvm.args='-Dlog4j2.formatMsgNoLookups=true'
And then restart any running servers.
AFAIKT the only published RCE against log4j v1.12.17 is CVE-2019-17571, which requires you to implement a Log4j SocketServer
I know the log4j project isn’t reporting new 1.x ones, but given all the heightened focus at the moment, I’m pretty sure someone would be posting about other ones for global fame.
As Lucee loads log4j via OSGI, it’s loaded into a separate classloader, which according to @micstriit who knows way more than anyone else on this thread about java, is another effective strategy against RCEs