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
Sort of. To be clear, OSGI does not in any way mitigate against RCE’s in general nor does it directly prevent a vulnerable version of Log4j from being exploitable. What it does do is limit the surface area of the attack vector. In other words, instead of Log4j being loaded globally in the system class loader and shared by the entire application, a hypothetical vuln version of Log4j loaded by a extension would only be visible/usable by the code in that extension, therefore limiting the amount of use and potentially the chances of it being exploitable. I’ll also add that Lucee makes classes from OSGI bundles available anywhere in the application via the environment class loader, which will iterate over bundles looking for a class if it’s not found in the main class loader. So the encapsulation of OSGI in Lucee is not strictly enforced (meaning your CFML code can call createObject( 'java' ... ) and wind up with a class from potentially any loaded bundle).
I scanned all of the bundles that come with Lucee out of the box with the tool I posted above, and none of them have Log4j 2.x, but it’s worth noting there could be extensions (either official LAS ext or community ones on ForgeBox) that could bundle any version of OSGI they choose that I didn’t scan, so I recommend you scan your entire Lucee server home if you’re curious about your specific setup.
We will not make any changes to Lucee 5 when it comes to logging, simply because the version we use is not vulnerable for the recent exploit. For once is having and old version a benefit.
For Lucee 6 we are moving to the latest version of log4j 2.
No it is not possible to simply update the log4j jar from on1e to 2, if that would be possible we would already done it a long time ago. This version are not compatible to each other.
My recommendation would be if you’re worried, replace 1.2.17 with this:
This is a fork that removes the vulnerable socket server and JMSAppender.
Or you could just modify the log4j-1.2.17 jar file to remove the classes. There’s numerous articles online that explain how, here’s one
I’d do that before I replaced w/ 1.2.18 - at least we know the MANIFEST is right in the jar already in the distro.
HOWEVER - I’m not looking at Lucee specifically. I don’t know if this jar has appropriate OSGI tags in the manifest, nor have I tested this solution.
Also be aware this may not cover you in all situations - for instance, some vendors use “shading” to embed libraries within their jars… i.e. instead of org.apache.log4j, they prefix with some.vendor.package.org.apache.log4j. The zip tool isn’t going to find that as a vulnerable class. Nor are the scanners going to see it as a vulnerable jar. That’s why this problem is so insidious. There are javaagent-based solutions to patch:
But these (as of now) do not help for Log4j 1.2
So, that’s what I know - everyone has to make their own risk assessment and do what they’re comfortable with.
Is setting an environment variable on the server (Windows in this case) advisable? As I understand it, it will set a global value.
Open a command prompt with elevated rights and run: SETX /m LOG4J_FORMAT_MSG_NO_LOOKUPS "TRUE"
Unfortunately our servers are flagged with critical vulnerabilities now, not necessarily because this version of log4j is vulnerable to log4shell, but because it is an unsupported version.
Are there any short-turnaround options? I’m even open to forking the codebase if needed.
Log4j2 support was committed to the 5.3.9 builds yesterday. You can test the snapshot builds on ForgeBox but I don’t know when 5.3.9 will release. There’s still quite a list of tickets for it in JIRA.
I spent several hours testing the Log4j 1 to 2 bridge, but it does not work. Lucee’s use of Log4j 1 is too complex
So, looking at the commit, Log4J2 support was added, but the legacy sources were not removed. Unfortunately, it is not sufficient for us to just add Log4J2, all traces of Log4J1 must be removed
