...
But that doesn't prevent an application deployed to Tomcat from using log4j2. In which case, please use general guidance on various remediations. As of this writing, they include any of these
- Upgrading log4j2 to 2.1516.0 (or better)
- This is the best fix (2.15.0 was also insufficient due to CVE-2021-45046)
- Use system property log4j2.formatMsgNoLookups=true to disable message formatting
- This is a reasonable workaround - But due to CVE-2021-45046 you may still have other vulnerabilities
- Setting a shell environment variable
LOG4J_FORMAT_MSG_NO_LOOKUPS=trueshould work too
- Remove the following files from your jar file: log4j-core-2.XX.Y.jar (This is a hack. A simple one but effective. This also remediates CVE-2021-45046)
org/apache/logging/log4j/core/net/JndiManager$1.class
org/apache/logging/log4j/core/util/JndiCloser.class
org/apache/logging/log4j/core/net/JndiManager$JndiManagerFactory.class
org/apache/logging/log4j/core/lookup/JndiLookup.class
org/apache/logging/log4j/core/net/JndiManager.class
org/apache/logging/log4j/core/selector/JndiContextSelector.class
- Ensuring your JRE is 1.8.121 or better. (This version doesn't fix the issue, it just eliminates one very easy to exploit attack vector.)
- Not recommended but better than nothing. When combined with the limiting of creating socket connections, this will make payloads harder (but not impossible) to deploy.
- But these 2 system properties must also be set to false (or unset) com.sun.jndi.rmi.object.trustURLCodebase,com.sun.jndi.cosnaming.object.trustURLCodebase
- Newer JVM's can still fall victim to this attack with the older log4j2. It is beyond the scope of this FAQ to explain how. But the TL;DR is it the exploit becomes more application or application server specific.
More details on these CVE's via the ASF blog