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)