Another Day, Another Log4j Vulnerability – InApps 2022

Dan Lorenc, founder and CEO of the open source security supply chain company Chainguard, joked with me after I said that, “Log4Shell may, with no exaggeration, be the worst IT security problem of our generation” by replying with a Simpsons meme, “worst day of your life so far.”

Then, I saw this: CVE-2021-45046, a new Log4j vulnerability, and it wasn’t so funny anymore.

https://t.co/uESQAtdKhG pic.twitter.com/x0elPczSlX

— Dan Lorenc (@lorenc_dan) December 14, 2021

First, the good news. This security problem isn’t anything as bad as the original. The first is going to keep you up at night for weeks, possibly months, to come. Don’t believe me? Just watch, kids.

Where It Came from

This new one arose because while the repairs that addressed CVE-2021-44228, Log4Shell, were good as far as they went, they didn’t go far enough. So, the fixed version, Apache Log4j 2.15.0, was “incomplete in certain non-default configurations.”

That’s not good, but with a CVSS Score: 3.7, moderate severity, that’s much better than Log4Shell’s 10 out of 10 disaster rating.

True, “This could allow attackers… to craft malicious input data using a JNDI [Java Naming and Directory Interface] Lookup pattern resulting in a denial of service (DOS) attack.” But this vulnerability only works with certain non-default configurations. Specifically, if the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data, then an attacker could get control over Thread Context Map (MDC) input data.

Gotcha! But Never Fear, a Fix Is Available

So that’s not too bad. But there’s a gotcha. Previous Log4Shell mitigations such as setting the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability. So, if you’ve been doing that to avoid Log4Shell, you may still be in trouble.

Fortunately, the Apache Foundation’s developers have already issued a fix, Log4j 2.16.0, for this new problem. This patch removes support for message lookup patterns and disables JNDI functionality by default. You can still mitigate it in earlier (<2.16.0) Log4Shell releases by removing the JndiLookup class from the classpath. For example:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Disabling JNDI Lookup

Does that make you think part of the fix is simply disabling JNDI Lookup functionality? If so, congratulations, you’re right. As the developers said, “The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.”

Matt Sicker, Apple software engineer and the Apache Foundation VP of Logging Services, explained further in a mailing list message, “the Log4j team feels that having JNDI enabled by default introduces an undue risk for our users.” Further, “Use of JNDI in an unprotected context is a large security risk and should be treated as such in both this library and all other Java libraries using JNDI.” Well, given what we’ve seen, you can’t argue with that! Therefore, from this version on, JNDI is disabled by default.

That’s good, but I can also see, first, many programs will need to be rewritten to deal with no longer having JNDI access. And two, I wonder what other unsanitized access to JNDI might be hiding in other Java libraries.

But the latter is a worry for another day. Now, if you’ll excuse me, I’m off to download and update everything to Log4j 2.16.0.

Feature Image par kulnor de Pixabay