Yes, I saw that as an option… The problem is that we don’t have the list of pathnames, they are mounted with different name variations and we have hundreds of clients doing that
2 Likes
Poll on Mitigation
As we are waiting for vendors to update their individual applications, the cyber community has coalesced on a couple of techniques that may mitigate the problem. Both of these involve modifying the Log4J JAR file. Both of these could have unintended consequences on the products using Log4J and thus come with an element of risk.
Method 1 would be to replace the JAR file entirely, with the latest log4j-2.16.0.jar. To avoid updating whatever application was using log4j, we would need for the new version of the file to retain the old version’s name. Something like
cp -y log4j-core-2.16.0.jar /opt/whatever-program/lib/log4j-2.14.0.jar
In this method, it would be much easier to track which JAR files have already been updated, because there is a single known hash for log4j-core-2.16.0.jar that all of the log4j-core should match once they are replaced.
Method 2, is to unpack the log4j-core-X.X.X.jar file and remove the affected library from the ClassPath via a command such as
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Windows lacks a zip command-line utility on Windows (we could download 7-zip to do this though), but the real complexity comes in knowing which files we have already fixed. Depending on the distribution, version of zip, etc., we could end up with an unknown number of resulting hash versions, so we would need some kind of log/tracking mechanism to know which ones have been fixed already.
So, I wanted to poll the community on which, if either, mitigation you’d like to see us pursue.
- Unpack the JAR and remove the Class
- Replace the JAR with 2.16.0
- Neither; I can only rely on official updates from the affected vendors.
0 voters
(Edit: re-ordered the descriptions to match the order of the poll questions)
1 Like
I have been working on something, will report tomorrow as going bed finally. Needs testing
Anyone found a way to determine whether the jar file is running the JndiLookup.class without having to run a script ?
Looking at command line arguments or a java process or similar ??
Need an output similar to what this command will show but using native relevance
Run below command to check whether it lists any jar files which contains vulnerable class.
find / -type f -name “*.jar” -exec sh -c “zipinfo -1 {} | grep JndiLookup.class && echo {}” ;
This won’t work. This is a per-user location, not system wide.
You don’t need to make a copy of the original txt file to do this, you can just use relevance to build the BAT file within a “create file” command.
That is definitely not intended. You want to exclude all network shares from scanning ideally.
If someone does actually want to go down this path, then it seems like this is the best way to do it on Windows/Linux: GitHub - logpresso/CVE-2021-44228-Scanner: Vulnerability scanner and mitigation patch for Log4j2 CVE-2021-44228 (from @Mario 's link above)
This is my preference, especially because we might not be done with Log4J CVEs and we might have to do this all over again with log4j-core-2.17.0.jar or similar in the future. I feel like if you already going to mess with things in weird ways, then “patching” it forward is better than removing things.
That said, using the environment variable, the logpresso scan and fix utility, and the replacing of the JAR files could all be done together. You don’t technically have to pick and choose which you do.
That said, the fix of removing the class file that the logpresso scan and fix utility does is not reversible as easily as renaming the affected JAR to something like JAR.20211215.backup and placing the new JAR in it’s place. I like the idea that just swapping out the JAR file for the fixed version is a much more easily reversible operation for either the application owner or for a bigfix operator.
The newest version of the script on github actually accounts for this now.
Oh damn, I definitely want this to be for everything, not interactive shells which are actually much less likely to be an issue. Things running as services are the most likely to be a problem. This is what I was worried about. It does seem like /etc/environment would be the right place if it exists and is used on the platform, but then annoying that other platforms have other locations.
If someone has example commands to address this for different OSes as far as setting env vars for system services, that would be extremely helpful.
CC: @QvR
1 Like
No, there is no native relevance to extract a zip file and look inside the contents. That will require an Action.
1 Like
More interested in the reporting. Based on the results from the scan you posted and the results file. Do you have a quick way to develop the action required to pipe the results of the lookup class to file ?
Can you be more specific? Not sure what an example input and desired output looks like, or which thing you are looking at.
Do you mean Jason Walker’s scan results using DIR/Find? or do you mean using the logpresso utility?
Some other feedback internally
I notice that in the scan, we are just looking at log4j-core*.jar files. I’m seeing that since the jndi class can be baked into any jar file or even jar files inside of jar files, is there a plan to expand this fixlet to do a deeper dive on all of the jar files on a system?
The scanners I have seen look to open up the jar files recursively, hash all the files inside, and match against the hashes of known vulnerable files.
1 Like
This is a gap most likely to be filled by something like the logpresso scan utility or similar. The pure DIR/FIND stuff won’t really do for that.
Trying to walk before I run.
I do have plans to eventually check inside WAR files for log4j-core, but I don’t think it’s safe to remove the JNDI class entirely from every JAR file. JNDI has valid uses, that just don’t include parsing user-provided strings the way Log4J is doing it.
2 Likes
Jasons script was great, but the lookup.class is just as importatnt as the vulnerable pathanmes/mitigation steps.
Looking at logpresso, that appears to do everything we need. Has anyone created a fixlet for this utility ?
1 Like
I only just now found out about it, but it seems to do everything needed if you are okay with the remove class approach. I can look at making one and output the results to a file in a similar location as Jason’s scan log.
1 Like
That would be great, BigFix is getting huge kudos right now on this. Time is of the essence.
Is there a way to not fix, just report ??
1 Like
I think if you exclude the following flags from the command line, it will report only
–fix
Backup original file and remove JndiLookup.class from JAR recursively.
–force-fix
Do not prompt confirmation. Don’t use this option unless you know what you are doing.
1 Like
You can do both with the utility, makes sense to have report only be the default.
Yes, similar to that. I was considering downloading 7zip to do it though, since some platforms may lack PowerShell and the Archive support can vary by PowerShell version.
1 Like
The logpresso utility handles this case and more.
1 Like