Yet Another Log4j Security Problem Appears – InApps 2022

Yes, another one. Fortunately, there’s already a patch available: Log4j 2.17.0.

You can’t make this stuff up. It was bad enough when the first Apache Log4j zero-day flaw CVE-2021-44228 with its “perfect” Common Vulnerability Scoring System (CVSS)  of 10 out of 10 was revealed. But, then, it was quickly followed up with another security vulnerability, CVE 2021-45046. This wasn’t that bad, but still bad enough. Then, Blumira discovered yet another way to exploit this pair of Log4j security problems. But wait! Now yet another new, fun independent Log4j security hole has been discovered: CVE-2021-45105!

Patch Is Available

Before you freak out completely, just like all the others, the patch to fix this is already available. To repair this one, you need to upgrade your Log4j library to Log4j 2.17.0.

The problem this time, Apache explained, was that the new 2.16 version “does not always protect from infinite recursion in lookup evaluation,” which made it vulnerable to a denial of service attack. While it’s not as bad as the original with a CVSS score of 7.5, it’s still more than bad enough.

This security weakness is present in all versions of Apache Log4j2 “from the first 2.0-alpha1 to 2.16.0.” None of them protect the library from uncontrolled recursion from self-referential lookups.

Thus, “When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process.” I think we all know what happens once you get locked into an infinite recursive lookup loop: Kaboom and a DoS.

Triggering this problem is alarmingly simple. You simply feed the application a poisoned string, and ta-da, instant crash.

Akamai Technologies’ Hideki Okamoto, Trend Micro Research’s Guy Lederfein, and an anonymous vulnerability researcher all discovered this issue. The problem is still being explored. As the malware study group, vx-underground tweeted, “the concern is that not all edge cases have been explored.” That said, the general consensus is that the best way to remediate this latest problem is to upgrade to Log4j 2.17.0.

Mitigating the Issue

You can mitigate it, by applying the 2.17.0 patch and replacing Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC) in PatternLayout in the logging configuration. Apache also suggested removing references to Context Lookups in the configuration like ${ctx:loginId} or $${ctx:loginId} where the strings originate from external application sources such as HTTP headers or user input.

As before, you need to get on top of this latest security vulnerability as soon as possible. As security researcher, Germán Fernández of CronUp pointed out, the Internet of Things (IoT) Mirai botnet has already added Log4Shell to its self-propagation arsenal as a worm. Fernández added it’s “Still a basic exploit but they already have it.”

If Mirai’s deploying it, it’s only a matter of hours until all the other botnets come knocking on your door attempting to bust your systems with Log4Shell attacks. Back to work my friends. A security analyst and developer’s work are never done.

Feature Image par Ylvers de Pixabay.