Critical Patch Update to Log4j Library Available with Apache 2.17.0 Release | Cybersecurity Breakthrough on ZDNET

Log4j: It’s bad and it’s only going to get worse

Video Player is loading.

Play Video

PlaySkip BackwardSkip ForwardNext playlist item

Mute

Current Time 0:00

Duration 7:08

Loaded: 1.37%

0:00

Stream Type LIVE

Seek to live, currently behind liveLIVE

Remaining Time -7:08

Playback Rate

Chapters

Chapters

Descriptions

descriptions off, selected

Captions

captions settings, opens captions settings dialog
captions off, selected
Eng US

Audio Track

en (Main), selected

Fullscreen

This is a modal window.

Beginning of dialog window. Escape will cancel and close the window.

TextColorWhiteBlackRedGreenBlueYellowMagentaCyanOpacityOpaqueSemi-Transparent

Text BackgroundColorBlackWhiteRedGreenBlueYellowMagentaCyanOpacityOpaqueSemi-TransparentTransparent

Caption Area BackgroundColorBlackWhiteRedGreenBlueYellowMagentaCyanOpacityTransparentSemi-TransparentOpaque

Font Size50%75%100%125%150%175%200%300%400%

Text Edge StyleNoneRaisedDepressedUniformDrop shadow

Font FamilyProportional Sans-SerifMonospace Sans-SerifProportional SerifMonospace SerifCasualScriptSmall Caps

ResetDone

Close Modal Dialog

End of dialog window.

Close Modal Dialog

This is a modal window. This modal can be closed by pressing the Escape key or activating the close button.

Facebook Twitter

Direct LinkEmbed Code

Close Modal Dialog

Apache has released version 2.17.0 of the patch for Log4j after discovering issues with their previous release, which came out on Tuesday .

more Log4j

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 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.

Google

“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.