JAVA_TOOL_OPTIONS = -Dlog4j.formatMsgNoLookups=true (preserving any existing entries)
JDK_JAVA_OPTIONS = -Dlog4j.formatMsgNoLookups=true (preserving any existing entries)
_JAVA_OPTIONS = -Dlog4j.formatMsgNoLookups=true (preserving any existing entries)
LOG4J_FORMAT_MSG_NO_LOOKUPS = true (overwriting any existing entry)
Again, I’m not at all confident in how effective this will actually be, as it depends on the startup scripts for whatever Java application to not clobber these values, and requires Log4j to be at one of the versions (2.11.0 - 2.14.0 I believe) that respects these values. But it may be useful in reducing attack surfaces while you wait for other applications to update or give their own workaround guidance.
Jason, I noticed the primary scans are for v2.x. Since v1.x is eol, my management is asking for that also (as they do not fully trust our Infosec scan results)
Can the 1.x hashes be included?
The scan as it is is running great btw. Good job to everyone who has worked on it.
Log4j 1.x versions have a different naming convention…I’m not sure what it is, and I don’t have a known hash list.
You could certainly update your copy of the scan task to widen the file filter, and then those results should show up in the Analysis, just with “No Match” on the hash values. Usually the version number might be apparent from the filename.
Just to reiterate though, it’s not just a matter of “1.x EoL and not evaluated”…for this particular thing, 1.x did not even provide the JNDI lookup function that’s being exploited, as far as I’ve read.
Thanks for the reply. Thinking about it now, I may setup a separate scan for 1.x to differentiate the issue. EOL vs vuln.
Once again thanks for all the work on the scan/analysis posted here.
I can confirm that this works as I have done the exact same thing as a test case on a dev server. As a curious question this setting reflected in the registry after manually changing the value. Does is stick permanently when done that way? Just thinking out loud as the Registry Wizard can then be used in this case if it is a permanent stick… I haven’t had a chance to test yet though.
The setx does stick after reboot. It should show up in the registry and in the environment variables control panel thingy right away. It will show up with relevance after reboot.
It won’t be effective for all services and things until after reboot.
It is specifically the MacOS and Linux actionscript I need testing on. I’ll add it to my existing content so it can be more easily tested.
Jason, I really appreciate your work. I’ve been looking for something like this. However, when scanning a server manually that I knew had oracle apps installed, I found that sqldeveloper contained a file named this, log4j-1.2.13.jar. So I’m running your task on the workstations to see what it pulls in, but should I expect that this task will find and record files without “core” in the name for the workstations? Sorry if this is a dumb question…Also, the job name says Mitigation in it, so is it somehow supposed to fix the issue, or just detect the vulnerabilities?
That is not found by Jason’s scanning task on purpose.
there are a bunch of different things going on here. The scanning task and analysis are only detecting the presence of the JAR files, that is all.
The newer mitigation fixlet/tasks are setting environment variables as a mitigation since it should be the safest thing you can roll out everywhere without making any other changes, yet disabling the vulnerable functionality.
After setting the environment variables, you still need to reboot and should probably do some verification, and probably still look to install updates from vendors when they become available, but at least this mitigation should be stopping the vulnerability.
History Older (discredited) mitigation measures This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open. Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1. The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf(“%s”, userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.
The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar. (Emphasis added).
For what it’s worth, removing the JndiLookup class is the recommendation from VMWare for VCenter Server…
Thank you for the clarification, JGStew. By the way, I really appreciate your work as well. I downloaded your updated fix about an hour ago and tested on my machine. I just wish there was some way, to KNOW, that any java library will respect that environment variable. Trying to convince our security team that I should push this out…
There is no harm in pushing out the LOG4J_FORMAT_MSG_NO_LOOKUPS as a quick and easy stop gap with basically no down side. That said, I can’t guarantee it will work in all cases, only that it SHOULD.
Even with this new CVE coming out that is a denial of service and not a remote code execution that is not solved by this env var, I think it is still advisable to put out this env var as a quick stop gap regardless.
The solution for the new CVE is probably going to entail replacing JAR files which is more risky from an application owner perspective, but a better fix from a security perspective. This approach will basically require Jason’s detection scan from above to get the list of JARs that need fixing.
All that said, I am only confident that the actionscript for the above LOG4J_FORMAT_MSG_NO_LOOKUPS fix works for windows. I need to test others.
I have an alternative mechanism for Windows I’m testing that doesn’t require scanning the entire hard drive and is thus significantly lower impact and much faster.
I am looking for folks who have a significant number of systems with JAVA that would be willing to test the content and report back results.
My intention is to make the content public once I have some feedback on the efficacy of the content.
Please send me a message if you’re interested in helping.