Log4Shell exploits are present in 17,000 unpatched Log4J packages in the Maven Central ecosystem, posing a significant supply-chain risk.
Google security estimates that approximately 17,000 Java packages in the Maven Central repository are vulnerable to Log4j – and that it will take “years” for it to be fixed across the ecosystem.
The Log4j bug impacts a tremendous amount of Java software. Threatrix can scan your code and locate every hiding place.
The incumbent Software Composition Analysis tools expose your organization to unnecessary risk since they only analyze dependency and package managers, with some only supporting 22 of the 400+ languages. The incumbents have limited detection breadth and fidelity of the results.
Our True Match technology gives us the unique ability to detect log4j embedded in your source code with extreme fidelity.
Gray checkmarks = limited coverage with limited languages
After the CVE update that Log4j-core was affected, updating all vulnerable versions of the Log4j-API, Google Security found that as of December 19, more than 17,000 packages in Maven Central were vulnerable or about 4 percent of the entire repository. Only 25 percent of them had updated versions available. In a blog post posted on Dec. 21st, Google researchers explained that the average bug affects between 2 percent and less than .01 percent of such packages.
Those are new downloads that leave apps and projects susceptible to Log4j attacks.
Work up from the deepest point in the supply chain
Log4j is embedded in “dependencies” on flawed code, either directly or indirectly, up and down the supply chain. Google explained.
“The majority of affected artifacts come from indirect dependencies (that is, the dependencies of one’s dependencies), meaning Log4j is not explicitly defined as a dependency of the artifact but gets pulled in as a transitive dependency,” the Google team said.
“For greater than 80 percent 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),” the report warned. “These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.”
What Makes Java Difficult Compared to Other Ecosystems
According to Google, Java’s “soft” version requirements make finding Log4j bugs even more complicated.
“Propagating a fix often requires an explicit action by the maintainers to update the dependency requirements to a patched version,” the Google researchers said. “This practice is in contrast to other ecosystems, such as npm, where it’s common for developers to specify open ranges for dependency requirements.”
There’s still a great deal left to do before Log4j is in the industry’s rearview for good.
“We looked at all publicly disclosed critical advisories affecting Maven packages to get a sense of how quickly other vulnerabilities have been fully addressed,” the team said. “Less than half (48 percent) of the artifacts affected by a vulnerability have been fixed, so we might be in for a long wait, likely years.” Google researchers stated.
The FTC will pursue companies that haven’t patched Log4j in order to protect customer data
A warning has been issued by the United States Federal Trade Commission that it will pursue companies that fail to correct the vulnerability in the Java logging package Log4j.
“The FTC intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future,” the agency said on Tuesday.
“Failure to identify and patch instances of this software may violate the FTC Act.”
As an example of what can happen if customer data is exposed, the agency cited its $700 million settlement with Equifax in 2019.
“The Log4j vulnerability is part of a broader set of structural issues. It is one of the thousands of unheralded but critically important open-source services that are used across a near-innumerable variety of internet companies,” the FTC said.
“These projects are often created and maintained by volunteers, who don’t always have adequate resources and personnel for incident response and proactive maintenance even as their projects are critical to the internet economy.
“This overall dynamic is something the FTC will consider as we work to address the root issues that endanger user security.”
Original article posted by znet.com
