Apache has released another Log4j version, 2.17.1 fixing a newly discovered remote code execution (RCE) vulnerability in 2.17.0, tracked as CVE-2021-44832.
Prior to today, 2.17.0 was the most recent version of Log4j and deemed the safest release to upgrade to, but that advice has now evolved.
Fifth Log4j CVE in under a month
Mass exploitation of the original Log4Shell vulnerability (CVE-2021-44228) by threat actors began around December 9th, when a PoC exploit for it surfaced on GitHub.
Given Log4j’s vast usage in the majority of Java applications, Log4Shell soon turned into a nightmare for enterprises and governments worldwide.
While the critical risk posed by the original Log4Shell exploit is paramount, milder variants of the vulnerability emerged in Log4j versions, including 2.15 and 2.16—previously believed to be fully patched.
BleepingComputer earlier reported on four different CVEs impacting Log4j and one discovered in the ‘logback’ framework. After the discovery of a DoS flaw in version 2.16, the advice had swiftly shifted towards upgrading to version 2.17.0, deemed the safest of all.
But now a fifth vulnerability—an RCE flaw, tracked as CVE-2021-44832 has been discovered in 2.17.0, with a patch applied to the newest release 2.17.1 which is out.
Rated ‘Moderate’ in severity and assigned a 6.6 score on the CVSS scale, the vulnerability stems from the lack of additional controls on JDNI access in log4j.
“JDBC Appender should use JndiManager when accessing JNDI. JNDI access should be controlled via a system property,” states the issue description seen by BleepingComputer.
“Related to CVE-2021-44832 where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code.”
Checkmarx security researcher Yaniv Nizry claimed credit for reporting the vulnerability to Apache:
Nizry’s tweet quickly exploded in traffic, attracting remarks and memes from security experts and ‘victims’ of the ongoing log4j-patching fatigue.
“I hope this is a joke, I hope so much… #log4j,” tweeted one user in response.
“We are LONG past the point where the only responsible thing to do is put up a giant flashing neon sign that reads ‘LOG4J CANNOT BE FIXED, DO NOT USE IT FOR ANYTHING.'” taunted another.
Security expert Kevin Beaumont labeled the instance another “failed Log4j disclosure in motion” during the holidays.
Disclosed too soon?
At the time of Nizry’s tweet, BleepingComputer did not see an official advisory or memo indicating the presence of an RCE bug in log4j 2.17.
The tweet itself contained no details about the vulnerability or how it could be exploited but, within minutes, led a pack of security pros and netizens to start investigating the claim.
Disclosing security vulnerabilities prematurely can lure threat actors to conduct malicious scanning and exploitation activities, as evident from the Log4Shell exploit leak of December 9th.
Marc Rogers, VP of cybersecurity at Okta first disclosed the vulnerability identifier (CVE-2021-44832) and that the exploitation of the bug depends on a non-default log4j setup where configuration is being loaded from a remote server:
Up until now, log4j vulnerabilities have been exploited by all kinds of threat actors from state-backed hackers to ransomware gangs and others to inject Monero miners on vulnerable systems.
The Conti ransomware gang has been seen eying vulnerable VMWare vCenter servers. Whereas attackers breaching the Vietnamese crypto platform, ONUS, via log4shell demanded a $5 million ransom.
Log4j users should immediately upgrade to the latest release 2.17.1 (for Java 8). Backported versions 2.12.4 (Java 7) and 2.3.2 (Java 6) containing the fix are also expected to be released shortly.
BleepingComputer has reached out to Checkmarx for comment in advance of writing and we are awaiting their response.
Update 4:45 PM ET: Checkmarx has published a blog post describing the vulnerability.
To read the original article: