This article is more than 1 year old

Bad things come in threes: Apache reveals another Log4J bug

Third major fix in ten days is an infinite recursion flaw rated 7.5/10

The Apache Software Foundation (ASF) has revealed a third bug in its Log4 Java-based open-source logging library Log4j.

CVE-2021-45105 is a 7.5/10-rated infinite recursion bug that was present in Log4j2 versions 2.0-alpha1 through 2.16.0. The fix is version 2.17.0 of Log4j.

That’s the third new version of the tool in the last ten days.

In case you haven’t been paying attention, version 2.15.0 was created to fix CVE-2021-44228, the critical-rated and trivial-to-exploit remote code execution flaw present in many versions up to 2.14.0.

But version 2.15.0 didn’t address another issue - CVE-2021-45046 - which allowed a remote attacker with control over Thread Context Map (MDC) to cook up malicious input using a JNDI Lookup pattern. The result could be remote code execution, thankfully not in all environments.

Version 2.16.0 fixed that problem.

But it didn’t fix CVE-2021-45105, which the ASF describes as follows:

Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. 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 input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process.

Vendor-agnostic bug bounty program the Zero Day Initiative has described the flaw as follows.

When a nested variable is substituted by the StrSubstitutor class, it recursively calls the substitute() class. However, when the nested variable references the variable being replaced, the recursion is called with the same string. This leads to an infinite recursion and a DoS condition on the server.

What to do?

You know the drill by now: download the latest version 2.17.0 of Log4J, here, and install it everywhere Log4j runs, which of course turns out to be everywhere (including in some hard-to-find places).

The ASF has also outlined the following mitigations:

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

Once you’re done, cross your fingers and hope the ASF has found all the flaws that need immediate fixes so we can all stop worrying about this piece of software over Christmas. ®

More about

TIP US OFF

Send us news


Other stories you might like