Apache Log4j Vulnerability explained by Google

On December 17th, 2021 in their blog Google Open Source Insights Team explained the whole situation they observed concerning Apache Log4j Vulnerability. They described the widespread vulnerability and current progress in fixing the open source JVM ecosystem. Also Team shared their thoughts on how long it will possibly take for this vulnerability to be fixed across the entire ecosystem and where to focus next.

On December 9th the information security ecosystem learned of the vulnerability’s existence that poses great degree of severity and widespread impact. Tens of thousands of software packages (artifacts in the Java ecosystem) and projects use a popular logging tool, log4j that turned out to have the vulnerabilities discussed. As specialists explain these vulnerabilities allow for the remote code execution by exploiting the diffident JNDI lookups feature laid bare by the logging library log4j. In many versions of the library the exploited feature existed by default.

Apache Log4j Vulnerability will take a while to fix

Not long ago disclosed log4j vulnerabilities touched more than 35,000 Java packages, numbering to over 8% of the Maven Central repository. With the repository being the most significant Java package repository it caused an extensive outcome for the software industry. Specialists point out that 8% is a huge result for the ecosystem outcome while the average number for the Maven Central advisories outcome goes with 2% and the median less than 0.1%. Though the numbers mentioned do not enclose all Java packages, for instance directly distributed binaries.

At the time of the post publishing nearly five thousand of the artifacts in question have been fixed. And over 30,000 artifacts, many dependent on another artifact, still wait to be patched. The Team mentions that they counted an artifact as fixed if the artifact had at least one version impacted and has released a greater unimpacted stable version (that’s according to semantic versioning). In the case of log4j an artifact is considered fixed if it has been updated to 2.16.0 or no longer has dependency on log4j.

Two significant problems hinder the fix process

Although the situations in general can be defined as clear, the specialists point out two significant fixing problems. The first objective they define is the fact that many artifacts depend on log4j indirectly. Those of direct dependencies account for around 7,000 of the affected artifacts. In such a case any of its versions depend upon an affected version of log4j-core or log4j-api, described in the CVEs. The indirect dependency or transitive dependency means the dependencies of one’s own dependencies.

All this dependency’s staff creates significant hinders in fixing if to look at it with dependency chains. Here everything stays quite clear: The deeper the vulnerability falls down, the more steps one should go to fix it. According to the Team`s consumers dependency graphs histogram results showed big numbers. In more than 80% of the packages vulnerability is more than one level deep. In majority of which it`s five levels down and in some nine levels down. The process of fixing will require going first to the deepest dependencies first and all tree afterwards.

Open ranges gives the opportunity to select the most recently released version

Another difficulty lies in ecosystem-level choices in the dependency resolution algorithm and requirement specification conventions. The practice differs from those such as npm where they routinely specify open ranges for dependency requirements. Open ranges gives the opportunity to select the most recently released version that satisfies dependency requirements. And it subsequently pulls in new fixes. Users receive a patched version on the next build after the availability of the patch. It generates the dependencies more quickly.

“In the Java ecosystem, it’s common practice to specify “soft” version requirements — exact versions that are used by the resolution algorithm if no other version of the same package appears earlier in the dependency graph. Propagating a fix often requires explicit action by the maintainers to update the dependency requirements to a patched version,” Open Source Insights Team wrote on this second one problem.

With these Team advises the open source community to enable automated dependency updates and add security mitigations. They also provided a list of 500 affected packages with some of the highest transitive usage. In the specialists opinion prioritizing these packages will facilitate fixing efforts and subsequently unblock more of the community. Team thanked those open source maintainers and consumers who have upgraded their versions of log4j.

For the question how long it would take to completely fix everything the Team expressed vague opinion. They say it is hard to know. If it`s all publicly disclosed critical advisories affecting Maven packages then the process might take a while. They say less than half (48%) of the artifacts that a vulnerability impacted have been fixed. But on the log4j front things seem to be promising with about 13% that have been fixed.