More than 35,000 Java packages impacted by Log4j flaw, Google warns
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2021-45046 | Remote Code Execution in Apache Log4j2 via Incomplete Log4Shell Fix CVE-2021-45046 is a remote code execution and information disclosure flaw in Apache Log4j2 (CWE-917) that resulted from an incomplete fix to CVE-2021-44228 (Log4Shell), leaving the Thread Context Lookup Pattern vulnerable in certain non-default configurations. It is triggered when an application logs attacker-controlled data using layouts or patterns that perform Thread Context (MDC) lookups, allowing crafted lookup expressions to be evaluated against untrusted input. A successful attacker can achieve remote code execution, or potentially information disclosure, on the affected service. Any deployment of Apache Log4j2 that relies on the affected non-default lookup configurations is exposed, which given Log4j2's ubiquity in Java applications and embedded products means a very large installed base. Exploitation is confirmed: the flaw is in CISA KEV (added 2023-05-01) with known ransomware use, and EPSS assigns a 100% probability of exploitation within 30 days. Do: Upgrade Log4j2 to 2.17.0 or later per vendor instructions (or 2.12.3/2.3.1 for the legacy 2.12/2.3 branches), since the 2.16.0 fix was itself incomplete in some non-default configurations. Where upgrading is not immediately possible, remove the JndiLookup class from the Log4j2 jar or disable lookup processing, and audit applications and dependencies that bundle Log4j2 while following the CISA KEV required action to apply vendor updates. | 9.0 | 100% | KEV ransomware |
| massmillions of Java deployments worldwide, with hundreds of thousands of internet-exposed services observed in public scans during the Log4Shell campaign |
Full article452 words · extracted from securityaffairs.com · click to collapse
Pierluigi Paganini
December 21, 2021
Google found more than 35,000 Java packages in the Maven Central repository that are impacted by flaws in the Apache Log4j library.
The Google Open Source Team scanned the Maven Central Java package repository and found that 35,863 packages (8% of the total) were using versions of the Apache Log4j library vulnerable to Log4Shell exploit and to the CVE-2021-45046 RCE.
“More than 35,000 Java packages, amounting to over 8% of the Maven Central repository (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities (1, 2), with widespread fallout across the software industry.” reads the report published by Google. “As far as ecosystem impact goes, 8% is enormous.”
The Google experts used the Open Source Insights, a project used to determine open source dependencies, to assess all versions of all artifacts in the Maven Central Repository.
The experts pointed out that the direct dependencies account for around 7,000 of the affected packages. Most of the affected artifacts are related to indirect dependencies.
“The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed. The following diagram shows a histogram of how deeply an affected log4j package (core or api) first appears in consumers dependency graphs.” reads the post published by the researchers. “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). These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.”
But since the vulnerability was disclosed, 13% of all vulnerable packages have been fixed (4,620).
How long will it take for this vulnerability to be fixed across the entire ecosystem?
It is not easy to answer this question, the experts analyzed the time spent to fix flaws reported in critical advisories affecting Maven packages and determined that only 48% of the artifacts affected by a vulnerability have been fixed.
Despite the rush in fixing Log4J in the last few days, the overall process could take several years.
“As part of our investigation, we pulled together a list of 500 affected packages with some of the highest transitive usage. If you are a maintainer or user helping with the patching effort, prioritizing these packages could maximize your impact and unblock more of the community.We encourage the open source community to continue to strengthen security in these packages by enabling automated dependency updates and adding security mitigations.” concludes Google.
Follow me on Twitter: @securityaffairs and Facebook
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – hacking, log4J)
[adrotate banner=”5″]
[adrotate banner=”13″]
Text extracted automatically; images, tables and formatting may be missing. Original: https://securityaffairs.com/125845/security/log4j-java-packages-flaws.html