@bennadel This tool (recommended on Slack by Tom King) seems good and simple to use.
2 Likes
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: https://www.microsoft.com/en-us/download/details.aspx?id=52685)
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?
2 Likes
@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.
2 Likes
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
2 Likes
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.
2 Likes
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.
4 Likes
so is Lucee susceptible to other Log4J 1.x exploits or not? are we safe for now?
Log4j 1.x is not vulnerable to the specific Log4JShell CVE, but is vulnerable to other things and tangential things. It has its own CVE’s.
For instance, it does have JNDI vulnerabilities but only if JMSAppender is used in the configuration.
AFAIK you cannot just replace Log4j 1.2 with 2.17 and have it work - they are NOT binary compatible.
https://logging.apache.org/log4j/2.x/manual/migration.html
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.
2 Likes
that 1.2.18 is interesting, but it’s impossible to evaluate due to whitespace/reformatting changes
@zackster have you / lucee team looked into the log4j 1.2 bridge? https://logging.apache.org/log4j/2.x/log4j-1.2-api/index.html
I’ve been so busy helping folks remediate, I haven’t had time to test these sorts of solutions yet. I’m curious if that would work on lucee.
–
Pete Freitag
Foundeo Inc.
1 Like
Our focus currently is upgrading Lucee 6 to support using a pluggable logging engine via extensions, including log4j2 as an option.
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"
As far as I understand, this env var is only applicable on log4j versions >=2.10 Lucee uses an older version that isn’t impacted by log4shell.
2 Likes
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
Thanks Brad, I’ll take a look and see if it’s something I can try to backport to 5.3.8
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 
5 Likes
6 Likes