Maybe Log4j vulnerabilities are like rats—for every one that’s visible, multiple others scurry beneath the surface. It’s too early to tell if that’s what will happen with Log4j.
But just a day or so after a damaging vulnerability was disclosed, another has come to light. This time it’s believed to be moderate in severity.
“A second vulnerability involving Apache Log4j was found on Tuesday,” according to a MITRE alert. “The description on the new CVE 2021-45046 said the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was ‘incomplete in certain non-default configurations.’”
“When a vulnerability is discovered and makes as much noise as Log4Shell, it invariably signals that there are additional vulnerabilities in the same software or fixes for that software and that triggers additional research and discovery,” said Casey Ellis, founder and CTO at Bugcrowd.
“The technique of abusing JNDI lookups with user-generated data has been around for years,” agreed Davis McCarthy, principal security researcher at Valtix. “With the attention CVE-2021-44228 has received, I wouldn’t be surprised if we saw a third CVE related to Log4j2.”
Ellis pointed out that “in this case, the initial fix provided was developed in a way that mitigated the exploitable symptom, but didn’t properly address the root cause.”
Indeed, Apache said the fix addressing “CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations,” according to the alert. “This could allow attackers with control over thread context map (MDC) input data when the logging configuration uses a non-default pattern layout with either a context lookup (for example, $${ctx:loginId}) or a thread context map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI lookup pattern resulting in a denial-of-service (DOS) attack.”
The alert said, “Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default.” But previous mitigations that involve “configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do not mitigate this specific vulnerability,” MITRE warned. “Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).”
Ellis said the situation “also highlights the dangerous dependency open source users have on libraries which power large portions of the Internet but are ultimately written and maintained by unfunded volunteers with limited available time.” He gave credit to “ the Log4j maintainers” who he said likely “had an even busier and more stressful week than those in cybersecurity and are working on fixing and improving Log4j’s resilience as quickly as they can.”
Incomplete fixes are often a result of rushing patches to fix vulnerabilities, noted John Bambenek, principal threat hunter at Netenrich. The solution, he said, “is to disable JNDI functionality entirely (which is the default behavior in the latest version).”
Since “at least a dozen groups are using these vulnerabilities,” immediate action should then be taken “to either patch, remove JNDI or take it out of the classpath—preferably all of the above,” said Bambenek.
Manu Singh, risk engineer at Cowbell Cyber, sees an opportunity to show “a real-life use case where cyberinsurers can step up and help businesses.”
Singh said that Cowbell Cyber notified its policyholders of the vulnerabilities. “And our risk engineering team is available to help,” said Singh. “This is crucial in the small and mid-size market where security and IT resources are limited.”
