Log4j gets a second update as security woes pile up

Less than a week from the initial disclosure of the high-profile Log4Shell vulnerability, the open source Log4j software has already received a second major update.

The Apache Software Foundation is now advising organizations running Log4j to update the logging tool to version 2.16.0, rather than last week's 2.15.0 build. Unlike last week's update, which limited functions of the vulnerable JNDI (Java Naming and Directory Interface) component, the 2.16.0 build disables the API entirely.

The update is due to the discovery of CVE-2021-45046, a denial of service (DoS) flaw related to the Log4Shell vulnerability that has been dominating headlines all week.

UPDATE 12/17: Apache updated the advisory for CVE-2021-45046, raising the severity from moderate to critical. The CVSS score, which was 3.7, is now 9.0. "Since this CVE was published security experts found additional exploits against the Log4j 2.15.0 release, that could lead to information leaks, RCE (remote code execution) and LCE (local code execution) attacks," Apache said.

According to Apache's notification on CVE-2021-45046, some systems that had installed the 2.15.0 update were still vulnerable to DoS attacks when, under specific configurations, a DoS can be triggered by way of a malformed JNDI request such as a URL request or password entry.

What is worse, security vendors believe the flaw will also allow attackers to subvert the mitigations that were advised for unpatched systems. LunaSec reported that Log4j version 2.14.1, which was given the previously posted mitigation procedures, would be subject not just to DoS, but to full remote code execution attacks.

"Fortunately, the scope of this is less because it requires that somebody sets the ThreadContext in order to exploit this," LunaSec CEO Free Wortley told SearchSecurity. "However, I'm sure that still exists in production at many places."

Apache also noted problems with previous recommendations for Log4Shell in its advisory for CVE-2021-45046. "This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open," the advisory said. "The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar."

There could also be more problems with the previous patch for Log4Shell. Security vendor Praetorian reported that the vulnerability could still be exploited to exfiltrate data from an application running Log4j 2.15.0. The researchers noted that updating to 2.16.0, where JNDI is disabled by default, prevents the attack.

Praetorian also published a proof-of-concept demonstration for the attack, but did not release technical details for it. The company recommended that customers upgrade to 2.16.0 immediately.