Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: Log4j 2.15.0 and previously suggested mitigations may not be enough - SANS Internet Storm Center SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network
https://isc.sans.edu/honeypot.html

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Log4j 2.15.0 and previously suggested mitigations may not be enough

According to a new Apache Log4j security bulletin, version 2.15.0 and the initially suggested mitigation measures do not completely address the  Log4Shell in certain custom configurations. 

It was discovered that version 2.15.0 would still be vulnerable when the configuration has a pattern layout containing a Context Lookup (for example, $${ctx:loginId}), or a Thread Context Map pattern %X, %mdc, or %MDC. In these cases, when the attacker manages to control the Thread Context values, JNDI lookup injections may be possible, resulting in JNDI connections. Version 2.15.0 limited JNDI connections to 'localhost’' but this possibility could result in a denial of service (DoS) or worse.

Therefore, a new version (2.16.0) has been made available to completely fix the issue (so far at least) associated with CVE-2021–45046 along with more effective mitigation measures for versions to 2.x versions:

  • 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

The mitigation measures previously reported, such as setting the log4j2.formatMsgNoLookups variable to ‘true’, is not considered fully effective. The advisory says:

 "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.".

So, if you could not upgrade to versions 2.15.0 or 2.16.0 and followed previous mitigations, you are advised to remove JndiLookup class from the log4j-core jar to mitigate the vulnerability. 

The advisory is available at: https://logging.apache.org/log4j/2.x/security.html

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Renato

84 Posts
ISC Handler
Dec 14th 2021
I think we should highlight that CVE-2021-45046 is for a DoS (lower Consequence) in certain non-standard configurations (lower Probability). A CVSS score has not been set yet but I think it is safe to say the risk calculation is a lot lower! This is not a reset-start-over class bug!

This will trigger honorary rounds for manufacturers / providers to perfect the good work they have done so far. But even for defenders that have not deployed 2.16.0 I think it should be safe to continue with the current tasks and look out for additional updates / advisory.
dotBATman

70 Posts
Read more at https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
dotBATman

70 Posts
Good Evening,

Has anyone looked at this tool on Github before?

https://github.com/logpresso/CVE-2021-44228-Scanner/blob/main/src/main/java/com/logpresso/scanner/Log4j2Scanner.java


Seems really helpful, but want to make sure it's safe to use!
Arty

2 Posts
Good Evening,


Has anyone looked at this tool before?

https://github.com/logpresso/CVE-2021-44228-Scanner/blob/main/src/main/java/com/logpresso/scanner/Log4j2Scanner.java

It seems really helpful, but just want to verify it's safe to use!
Arty

2 Posts

Sign Up for Free or Log In to start participating in the conversation!