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.
