A team of researchers from the UC Berkeley School of Information have discovered that the Log4Shell vulnerability — a widely-reported cybersecurity issue discovered in late 2021 — still has not been patched in many applications, especially those that use the Log4Shell indirectly. A fixed version of Log4j has been available for over four months.
“This is a call to action for the open-source software industry to fix critical vulnerabilities,” says Muhammad Akhtar, one of the researchers who conducted the research, which was funded in part by the Center for Long-Term Cybersecurity. “Otherwise there is a good chance an attacker will be able to exploit the vulnerability on a library or application that uses Log4j indirectly.”
Log4j is a popular logging framework used by java application developers to log important contextual data to the application console for analysis, debugging, and other purposes. In December, many versions of Log4j version 2 were impacted by a remote code execution vulnerability called Log4Shell, which allowed an attacker to send an arbitrary payload that compromised the underlying application, allowing an attacker to gain full access to the system.
While a patch was made available shortly after the discovery of Log4Shell, the research team — called V-Cube — hypothesized that many applications remained vulnerable because a dependent library may be accessing the Log4j indirectly. When there are multiple layers of dependencies between libraries, this chain of dependency results in multiple “hops” from an application to a vulnerability.
The researchers’ study focused on whether a greater number of “hops” makes it harder to detect and fix a vulnerability. They conducted their analysis using downloaded libraries from Maven Central, a popular public repository of all Java open source libraries, and building a graph structure to connect all libraries.
Their analysis confirmed their hypothesis that when vulnerable libraries are buried deep inside the software dependency chain, developers are less likely to patch, possibly due to a lack of awareness that a vulnerability is present inside their application, or due to the unavailability of a patched version for a direct dependent library. Their research identified that fewer than five percent of open source library versions on Maven Central use the fixed version of the Log4j library. (See a more detailed description of the research methodology below.)
The team estimates that several thousand organizations could be impacted as these libraries, when referenced, become part of an organization’s internal source code. “We believe that developers find it difficult to fix open-source library vulnerabilities in their applications due to lack of visibility surrounding which libraries are getting used,” Akhtar says. “Our research shows that, even after four months, most of the libraries remain unpatched. Developers need better visibility tools that provide software bills of material to better understand the supply chain and identify indirect dependencies in their application.”
