Log4Shell – Log4j Exploit , A New(er) Variant – Blog 4

“A new day, a new variant” is an all too familiar headline and unfortunately, we are discussing this again in the world of Log4j vulnerabilities.

As discussed in our blog on December 15th, rapid software releases are not uncommon when major zero-day exploits are uncovered. The Apache team has spotted another gap in 2.16.0 where it does not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over the Thread Context Map data to cause a denial of service when a crafted string is interpreted. Interestingly, it was previously fixed in 2.12.3.

As such, this is being treated as a new vulnerability – another CVE-ID has been opened (CVE-2021-45046) and Apache has released a new fix in the form of 2.17.0 (release notes here).

The current advice (assuming you’re on Log4j 2.x, Java 8 or later and using the log4j-core JAR file) is to:

  • Patch systems to v2.17.0.

OR

  • In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).

Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

Note, other premutations and caveats apply and the latest documentation from Apache should always be reviewed here.

Options have updated our Firewall IPS signatures and vulnerability scanners accordingly. We are applying v2.17.0 to any system that we patched to v2.16.0 and using v2.17.0 going forward or applying vendor patches/mitigation steps as they are released.

For the avoidance of doubt, we are also patching 2.12.3 (which is technically not susceptible to this vulnerability) to 2.17.0.

To summarise, version 2.17.0 will now address each of these vulnerabilities:

To learn more about Options Managed Security offering, click here.

  • Options InfoSec Committee.