The recently issued log4j version 2.16.0 update, which was urgently released after the 2.15.0 fix was deemed incomplete, contains a denial of service bug, developers have found.
"If a string substitution is attempted for any reason on the following string, it will trigger an infinite recursion, and the application will crash: ${${::-${::-$${::-j}}}}," the reporter of the bug wrote.
A new version of log4j, 2.17.0 is out that handles the denial of service condition.
Log4j versions 2.14.0 and earlier contain an easily exploitable remote code execution vulnerability, that is currently under automated attacks.
Ecosystem impact "enormous"
Separately, Google's Open Source Insights Team scanned the most important Java repository, Maven Central, and found that almost 36,000 or eight percent of packages there have at least one version that is affected by the log4j vulnerability.
"As far as ecosystem impact goes, eight percent is enormous. The average ecosystem impact of advisories affecting Maven Central is two percent, with the median less than 0.1 percent," OSIT wrote.
OSIT found that 35,863 of available Java artifacts on Maven Central depend on the vulnerable log4j code as of December 17.
Almost 5000 artifacts have now been fixed, but OSIT considers them remedied if they have been updated to 2.16.0 which is itself vulnerable to a denial of service condition.
Fixing the vulnerability is made harder by Java artifacts depending on log4j indirectly, OSIT said.
Over 80 percent of packages are vulnerable more than one level down, with the majority affected five levels down.
The vulnerability can be nested as deep as nine dependencies down in some packages, OSIT said.
Another issue making fixing the log4j vulnerability difficult is the practice of specifying "soft" version requirements, OSIT said.
These are the exact versions used by the dependency resolution algorithm, and often require explicit action by maintainers to propagate fixes.
OSIT said it's hard to say how long it will take for the log4j vulnerability to be fixed, and that it might take years to do so.
Nevertheless, OSIT said that things are looking promising on the log4j front, with maintainers, infosec teams and consumers putting in a massive effort to fix the issue.
