Editors Observe:
The beneath numbers have been calculated based mostly on each log4j-core and log4j-api, as each have been listed on the CVE. Since then, the CVE has been up to date with the clarification that solely log4j-core is affected.
The ecosystem impression numbers for simply log4j-core, as of nineteenth December are over 17,000 packages affected, which is roughly 4% of the ecosystem. 25% of affected packages have mounted variations out there.
The linked checklist, which continues to be up to date, solely contains packages which depend upon log4j-core.
##
Greater than 35,000 Java packages, amounting to over 8% of the Maven Central repository (essentially the most important Java package deal repository), have been impacted by the not too long ago disclosed log4j vulnerabilities (1, 2), with widespread fallout throughout the software program trade. The vulnerabilities enable an attacker to carry out distant code execution by exploiting the insecure JNDI lookups characteristic uncovered by the logging library log4j. This exploitable characteristic was enabled by default in lots of variations of the library.
So far as ecosystem impression goes, 8% is gigantic. The typical ecosystem impression of advisories affecting Maven Central is 2%, with the median lower than 0.1%.
Direct dependencies account for round 7,000 of the affected artifacts, that means that any of its variations depend on an affected model of log4j-core or log4j-api, as described within the CVEs. The vast majority of affected artifacts come from oblique dependencies (that’s, the dependencies of 1’s personal dependencies), that means log4j isn’t explicitly outlined as a dependency of the artifact, however will get pulled in as a transitive dependency.
We counted an artifact as mounted if the artifact had at the very least one model affected and has launched a larger steady model (in line with semantic versioning) that’s unaffected. An artifact affected by log4j is taken into account mounted if it has up to date to 2.16.0 or eliminated its dependency on log4j altogether.
On the time of writing, practically 5 thousand of the affected artifacts have been mounted. This represents a speedy response and mammoth effort each by the log4j maintainers and the broader group of open supply shoppers.
That leaves over 30,000 artifacts affected, lots of that are depending on one other artifact to patch (the transitive dependency) and are doubtless blocked.
Why is fixing the JVM ecosystem laborious?
Most artifacts that depend upon log4j accomplish that not directly. The deeper the vulnerability is in a dependency chain, the extra steps are required for it to be mounted. The next diagram reveals a histogram of how deeply an affected log4j package deal (core or api) first seems in shoppers dependency graphs. For larger than 80% of the packages, the vulnerability is a couple of degree deep, with a majority affected 5 ranges down (and a few as many as 9 ranges down). These packages would require fixes all through all elements of the tree, ranging from the deepest dependencies first.
One other issue is brought on by ecosystem-level decisions within the dependency decision algorithm and requirement specification conventions.
Within the Java ecosystem, it’s widespread apply to specify “delicate” model necessities — precise variations which can be utilized by the decision algorithm if no different model of the identical package deal seems earlier within the dependency graph. Propagating a repair typically requires specific motion by the maintainers to replace the dependency necessities to a patched model.
This apply is in distinction to different ecosystems, resembling npm, the place it’s widespread for builders to specify open ranges for dependency necessities. Open ranges enable the decision algorithm to pick out essentially the most not too long ago launched model that satisfies dependency necessities, thereby pulling in new fixes. Shoppers can get a patched model on the following construct after the patch is offered, which propagates up the dependencies shortly. (This method isn’t with out its drawbacks; pulling in new fixes may also pull in new issues.)
How lengthy will it take for this vulnerability to be mounted throughout your complete ecosystem?
However issues are trying promising on the log4j entrance. After lower than every week, 4,620 affected artifacts (~13%) have been mounted. This, greater than every other stat, speaks to the huge effort by open supply maintainers, data safety groups and shoppers throughout the globe.
We encourage the open supply group to proceed to strengthen safety in these packages by enabling automated dependency updates and including safety mitigations. Enhancements resembling these may qualify for monetary rewards from the Safe Open Supply Rewards program.
You possibly can discover your package deal dependencies and their vulnerabilities by utilizing Open Supply Insights.
