Is CVE-2022-42889 the next Log4Shell? Not really.

In the past few days, there has been a frenzy about patching CVE-2022-42889. Amid the chaos, there have been some misunderstandings about the vulnerability, especially comparisons with last year’s CVE-2021-44228 (aka Log4Shell). But comparing this new vulnerability with Log4Shell is technically dubious, at best. Let me explain.

‍

What is CVE-2022-42889 anyway?

The alleged CVE-2022-42889 vulnerability is related to the (mis)configuration of a string interpolation (text templating) feature in the Apache Commons Text library. Prior to version 1.10.0, various lookup routines that may result in remote code execution when enabled were not disabled by default. That’s it. That really is the entirety of the CVE.

In codebases where templates provided to this functionality are strictly application-defined constants, there is zero vulnerability to this CVE, even in situations where the codebase uses an earlier version than 1.10.0. The decision made to not lock down these higher risk lookup routines in versions prior to 1.10.0 only results in a vulnerability when user-controlled input is provided as a template, which enables a class of attacks known as string interpolation attacks.

‍

Should CVE-2022-42889 even be a CVE?

Code that allows user-controlled input to be evaluated as a template is a security weakness no matter what. It is always the responsibility of the developer to ensure that user-controlled input is sanitized before using it in a trusted security context, so many people are likely wondering, why, given the above paragraphs, this has a CVE.

‍

After all, you know what the answer to “doctor, it hurts when I do that” usually is.

However, part of the purpose of the CVE database is to identify known weaknesses in software configurations. Although I disagree with the characterization that Apache Commons Text contains an exploitable vulnerability in its own right, I do think CVE-2022-42889 qualifies as a configuration error that happens to be CVE worthy, given the amount of exposure it enables when a StringInterpolator object is misconfigured.

In other words, yes, CVE-2022-42889 is a valid CVE. But every exploitation vector making use of it should also be a CVE.

‍

Is Log4Shell directly related to this CVE?

The astute observer will note that the expression language used by Apache Commons Text (e.g.) is the exact same expression language used by Log4J. This shouldn’t be a surprise, as both projects come from the same place: Apache.

${file:UTF-8:/etc/passwd}

Indeed, due to the similarities of the expression language, I originally concluded that Log4Shell itself was an example of practical exploitation of CVE-2022-42889. The reality is perhaps more surprising: it turns out that the expression language in Apache Commons Text was a reimplementation of Log4j’s string interpolation, likely to avoid pulling in all of Log4J Core for basic string interpolation. Unfortunately, Apache Commons Text happened to have the same basic design flaw as Log4j. Although I do not expect this exposure to be as severe as Log4Shell, this vulnerability, which stems from the same underlying weakness that led to Log4Shell, hopefully highlights how user data passed into a templating feature can result in carnage.

‍

Is The End of [Insert X]4Shell Near?

This will not be the end. There are likely hundreds of libraries and many more applications out there that are not properly sanitizing their inputs to these templating functions. From those libraries and applications, we will see more CVEs, and much like the format string attacks in the C and C++ ecosystems in the 90s and 2000s (what’s old is new again), fixing them all will be a war of attrition, but thanks to proactive actions like the Apache security team issuing CVE-2022-42889, it will eventually be won.

‍

The good news is that thanks to the widespread exploitation we saw with Log4Shell, most web application firewall vendors already have rulesets that will block new variations of these attacks targeted at other vulnerable dependencies. Finally, everyone should take this opportunity to audit their codebases and ensure their code abides by the guidelines in CWE-134. By ensuring that your own applications maintain good hygiene regarding user input, you can ensure they are not vulnerable to any CVE that falls under the CWE-134 umbrella (and many others).

‍

At Chainguard, we have deployed a policy in Chainguard Enforce that allows current customers to quickly identify if this vulnerability is present in your environment and offers remediation guidance. Learn more in our blog post.