By security practitioners, for security practitioners novacoast federal | Pillr | novacoast | about innovate
By security practitioners, for security practitioners

Apache Releases Log4j 2.16.0 to Patch Lingering DoS Vulnerability

Amid the focus on Log4j while patching CVE-2021-44228, a JNDI injection RCE vulnerability, Apache has released 2.16.0 which disables JNDI by default and removes support for Message lookups in order to fix a newly discovered denial of service vulnerability.

What’s the nature of the vulnerability?

 Background on Log4Shell can be found in our original Log4j / Log4Shell recommended guidance article. 

2.15.x does not introduce a new vulnerability, rather it highlighted the extent of issues with JNDI that lingered after the original patch was released.

While Log4Shell is a remote code execution vulnerability fixed in Log4j 2.15.x, the newly announced CVE-2021-45046 is a denial of service vulnerability that’s still present in 2.15.x, but patched in 2.16.0. The DoS vulnerability is rated much lower at CVSS 3.7

In 2.15.x, JNDI lookups are still only restricted to localhost by default. 2.16.0 fixes this issue by removing support for Message lookup patterns and disables JNDI functionality by default.

In 2.16.0 log4j2.enableJndi must be deliberately set to true in order to enable JNDI lookups.

Denial of Service

In certain logging configurations, such as a non-default Pattern Layout, Log4j is vulnerable to a DoS if attackers with control over Thread Context Map (MDC) input specially crafted data.

A Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) are example vulnerable configs.

Denial of Service is certainly a lower severity exploit than remote code execution but the high profile nature of Log4j vulnerabilities has resulted in a high number of recorded exploitation attempts. Because of this, risk of unpatched Log4j instances is higher than normal.

What can I do?

Mitigation procedures remain the same for those unable to upgrade or still waiting for vendor updates:

  • In releases >=2.10, the behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
  • For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
  • For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.


Previous Post

Log4j/Log4Shell Updates and Recommended Guidance

Next Post

A Data Security Primer

Innovate uses cookies to give you the best online experience. If you continue to use this site, you agree to the use of cookies. Please see our privacy policy for details.