Application security, Patch/Configuration Management

Log4j, again, needs patching as new bug is found and squashed

Officials at the Cybersecurity and Infrastructure Security Agency said Monday that “significant intrusions” related to the Log4j vulnerability have yet to be found in the systems of U.S. federal agencies or critical infrastructure sectors, but stressed that they lack the necessary visibility to fully assess the bug’s impact. (Photo: iStock/Getty Im...
While a new Log4j CVE was issued today, security researchers say it's actually an LCE -- local code execution -- making the severity much less than a remote code execution (RCE) vulnerability. Photo: iStock/Getty

Researchers at Checkmarx discovered a way to use Log4j to launch malicious code, forcing yet another round of patching for affected users.

Patched in Log4j 2.17.1, 2.12.4, and 2.3.2 — just as security staff were completing updates to 2.17.0 — Checkmarx researchers noticed the JDBCAppender function could still dynamically load JDNI URLs. JDBCAppender outputs logs over the Java Database Connectivity API.

Early Tuesday, Checkmarx researcher Yaniv Nizry posted a screenshot of an email confirming the vulnerability on Twitter and telling followers to stand-by for a blog post. The subject line to the email referred the Log4j remote code execution vulnerability already being patched, which many read to say the new vulnerability was also an RCE. It's not.

"To clarify, this is an LCE (local code execution) vulnerability, not a Remote Code Execution vulnerability. The severity is much lower than Log4Shell and requires a configuration modification," he later clarified.

Checkmarx issued a blogpost on the new bug late today. In it, Nizry argued that the newly-issued CVE-2021-44832 demonstrates how complex remediation is across the Log4j codebase.

"The Log4j team at Apache has worked hard to add security patches to the latest Log4j version (2.17.0) to disable lookups and allow a protocols/hosts list. As you can see, using a different attack vector, it is still possible to achieve an arbitrary code execution using the default configuration," he writes.

The Log4j CVE being released today requires a fairly obscure set of conditions to trigger, said Casey Ellis, founder and CTO at Bugcrowd. So, while it's important for people to keep an eye out for newly released CVEs for situational awareness, this CVE doesn't appear to increase the already elevated risk of compromise via Log4j. 

Ellis said the vulnerability also appears to have been discovered through the use of static code analysis tools in conjunction with manual review/exploit development. As a logging library, Ellis said Log4j is inherently flexible in terms of how data can be passed to it - each of these points of interaction is a potential vector for exploitation, and many eyes are currently scouring Log4j, so it’s fairly safe to expect more of this type of vulnerability announcement over the coming weeks."

"In the interest of staying as up-to-date as possible with Log4j - especially if the configurations required for exploiting CVE-2021-44832 - patching to 2.17.1 is a good idea," Ellis said.

Even before this new round of patching undoes the previous round of updates, experts were already anticipating Log4j clean-up efforts would take months or years. Log4j remains one of the most ubiquitous open source projects for Java, handling much of the logging performed by any app in that language.

Joe Uchill

Joe is a senior reporter at SC Weekly, focused on policy issues. He previously covered cybersecurity for Axios, The Hill and the Christian Science Monitor’s short-lived Passcode website.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.