A second Log4j vulnerability (CVE-2021-45046) was reported on Tuesday, prompting Apache to immediately issue a patch, Log4j 2.16.0.
According to the latest CVE, researchers found that the fix to address CVE-2021-44228 (the first known vulnerability) in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. The new CVE said this could potentially let attackers craft malicious input data using a Java Naming and Directory Interface (JNDI) “lookup” pattern, resulting in a denial of service (DoS) attack.
Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default.
When a vulnerability gets discovered and makes as much noise as Log4Shell, it signals that there are additional vulnerabilities in the same software or fixes for that software and triggers additional research and discovery, said Casey Ellis, founder and CTO at Bugcrowd. In this case, Ellis said the initial fix was developed in a way that mitigated the exploitable symptom, but didn't properly address the root cause.
“This 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,” Ellis said. “Props should be given to the Log4j maintainers, who I'm sure have 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.”
John Bambenek, principal threat hunter at Netenrich, added that rushing patches to fix vulnerabilities means that the fix may not be complete, and that’s the case here.
“The solution is to disable JNDI functionality entirely, the default behavior in the latest version,” Bambenek said. “At least a dozen groups are using these vulnerabilities, so quick action should be taken to either patch, remove JNDI, or take it out of the classpath. If at all possible, all of the above.”
Tomer Bar, director of security research at SafeBreach, said it’s been reported that the second vulnerability requires a non-default configuration.
“My estimation is that some servers are still vulnerable, but it should be a smaller amount in comparison to the number of vulnerable servers to the first vulnerability.”
