{"id":44496,"date":"2021-12-18T18:05:07","date_gmt":"2021-12-18T18:05:07","guid":{"rendered":"http:\/\/59ed1efa-e7ea-4860-b906-03680e127ca9"},"modified":"2021-12-18T18:05:07","modified_gmt":"2021-12-18T18:05:07","slug":"apache-releases-new-2-17-0-patch-for-log4j-to-solve-denial-of-service-vulnerability","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/apache-releases-new-2-17-0-patch-for-log4j-to-solve-denial-of-service-vulnerability\/","title":{"rendered":"Apache releases new 2.17.0 patch for Log4j to solve denial of service vulnerability"},"content":{"rendered":"

Apache has released version 2.17.0<\/a> of the patch for Log4j after discovering issues with their previous release, which came out on Tuesday<\/a>. <\/p>\n

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>, a denial of service vulnerability. They said the severity is “high” and gave it a CVSS score of 7.5.<\/p>\n

“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. <\/p>\n

They added that the latest issue was discovered by Akamai Technologies’ Hideki Okamoto and an anonymous vulnerability researcher.<\/p>\n

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.<\/p>\n

They noted that only the Log4j-core JAR file is impacted by CVE-2021-45105. <\/p>\n

On Friday, security researchers online began tweeting about potential issues<\/a> with 2.16.0, with some identifying the denial of service vulnerability<\/a>. <\/p>\n

<\/section>\n

Discussion about Log4j has dominated conversation all week. CISA released multiple advisories<\/a> mandating federal civilian agencies in the US apply patches before Christmas<\/a> while several major tech companies<\/a> like IBM, Cisco and VMware have raced to address Log4j vulnerabilities in their products. <\/p>\n

Security company Blumira claims to have found a new Log4j attack vector<\/a> 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.<\/p>\n

Other cybersecurity firms have found that major ransomware groups like Conti<\/a> are exploring ways to take advantage of the vulnerability. <\/p>\n

Google released a security report<\/a> 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. <\/p>\n

“The average ecosystem impact of advisories affecting Maven Central is 2%, with the median less than 0.1%,” Wetter and Ringland said. <\/p>\n

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. <\/p>\n

\"visualization-13.png\"<\/span>