Apache has released version 2.17.0 of the patch for Log4j after discovering issues with their previous release.
Apache said version 2.16 “does not always protect from infinite recursion in lookup evaluation” and explained that it is vulnerable to CVE-2021-45105, a denial of service vulnerability. They said the severity is “high” and gave it a CVSS score of 7.5.
“Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack,” Apache explained.
They added that the latest issue was discovered by Akamai Technologies’ Hideki Okamoto and an anonymous vulnerability researcher.
Mitigations include applying the 2.17.0 patch and replacing Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC) in PatternLayout in the logging configuration. Apache also suggested removing references to Context Lookups in the the configuration like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.
They noted that only the Log4j-core JAR file is impacted by CVE-2021-45105.
On Friday, security researchers online began tweeting about potential issues with 2.16.0, with some identifying the denial of service vulnerability.
Discussion about Log4j has dominated the conversation all week. CISA released multiple advisories mandating federal civilian agencies in the US apply patches before Christmas while several major tech companies like IBM, Cisco and VMware have raced to address Log4j vulnerabilities in their products.
Security company Blumira claims to have found a new Log4j attack vector that can be exploited through the path of a listening server on a machine or local network, potentially putting an end to the assumption that the problem was limited to exposed vulnerable servers.
Other cybersecurity firms have found that major ransomware groups like Conti are exploring ways to take advantage of the vulnerability.
Google released a security report on Friday where Open Source Insights Team members James Wetter and Nicky Ringland said they found that 35,863 of the available Java artifacts from Maven Central depend on the affected Log4j code. This means that more than 8% of all packages on Maven Central have at least one version that is impacted by this vulnerability, the two explained.
“The average ecosystem impact of advisories affecting Maven Central is 2%, with the median less than 0.1%,” Wetter and Ringland said.
So far, nearly 5,000 artifacts have been patched, leaving more than 30,000 more. But the two noted that it will be difficult to address the issue because of how deep Log4j is embedded in some products.
“Most artifacts that depend on log4j do so indirectly. The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed. For greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down),” Wetter and Ringland wrote.
“These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.”
The two went on to say that after looking at all publicly disclosed critical advisories affecting Maven packages, they found less than half (48%) of the artifacts affected by a vulnerability have been fixed, meaning it may take years for the Log4j issue to be solved.
(Except for the headline, this story has not been edited by The Technology Express staff and is published from a syndicated feed)
About Author
