Thanks @RexRobichaux and others! No-sleep Randall is still trying to keep up.
I'm sure inquiring minds and IT departments want to know and are asking:
"WAIT WAIT WAIT - the version numbers on those files have NOT CHANGED! WHERE'S MY LOG4J 2.16 ERMAGERD!!""
Here's the deal:
A. check out Apache's statement: https://logging.apache.org/log4j/2.x/security.html
Log4j 2.x mitigation: Implement one of the mitigation techniques below.
- Java 8 (or later) users should upgrade to release 2.16.0.
- Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
- Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
For expediency, we have elected to take the third option. It eliminates the source of the vuln - which is the fact that JNDILookup was enabled by default. The fix Apache provided in Log4J 2.15 was to make this an OPTIONAL tool. We have eliminated this class altogether.
Like I mentioned in an earlier reply, we'd dearly love to just upgrade Log4j and make everyone's vuln scanners test clean. That's just not realistic this early in the game.
Think about this in term of other vendor patches - a Microsoft patch for any give issue might go through multiple iterations before an issue is fully fixed. It's easily possible that even if we could patches for all upstream vendors aligned, Apache will release Log4J 2.17 to fix a whole different but similar issue. None of us have time to chase that. So we've provided what we can provide NOW based on the Log4J docs to mitigate this issue and help make you safe while this continues to shake out.
This won't be the last issue to shake the internet - that's the only thing I can promise without any doubt.