Log4j Vulnerability Alert: 100s of Exposed Packages Uncovered in Maven Central

The high risk associated with newly discovered vulnerabilities in the highly popular Apache Log4j library – CVE-2021-44228 (also known as Log4Shell) and CVE-2021-45046 – has led to a security frenzy of unusual scale and urgency. Developers and security teams are pressed to investigate the impact of  Log4j vulnerabilities on their software, revealing multiple technical challenges in the process.

Since Log4Shell was publicized, the JFrog Security Research team set out to help the developer community deal with the new threat as quickly and efficiently as possible. As we analyzed the issue, we found that using project dependencies to detect possible inclusions of Log4j in the code, while valuable, does not detect all instances of Log4j code in use. This means that relying solely on dependency scanning can leave vulnerable applications unnoticed. To provide additional detection capabilities, we released specialized Log4j vulnerability scanning tools designed to identify the presence and utilization of Apache Log4j in both source code and binaries.

In our recent blog post: “Log4j Detection with JFrog OSS Scanning Tools” we outlined the approach we implemented to improve Log4j vulnerability detection by scanning beyond package dependencies. The following are new findings gathered while using our new OSS tools to scan Java packages in the Maven Central repository.

The Importance of In-Depth Scanning for Log4Shell Vulnerability

The obvious (but incomplete!) way to check for exposure to Log4Shell is to see whether a vulnerable version of Log4j is listed as a dependency of a project in the build configuration (`pom.xml`, `gradle.build` etc.). A more accurate, but admittedly more time consuming approach is to check whether Log4j is included as a transitive dependency (`gradle -q dependencies` or `mvn dependency:tree`). Somewhat surprisingly, this method is also incomplete, and deeper investigation is required to make sure the final product does not contain vulnerable Log4j code.

The reason that scanning the full dependencies list may miss instances of included Log4j code is because dependencies only specify external packages needed to build or run the current artifact. If the vulnerable code is inserted directly into the codebase, it is not a dependency. Therefore, for more precise detection of vulnerable Log4j code, we need to inspect the code itself.

Log4j Inclusion In Packages – Findings in Maven Central

In previous research, approximately 17,000 Java packages in the Maven Central repository were found to contain the vulnerable log4j-core library as a direct or transitive dependency. Our investigation was focused on identifying additional packages containing the Log4j vulnerability that would not be detected through dependency scanning – namely, packages containing vulnerable Log4j code within the artifact itself.

We surveyed the latest versions of packages in Maven Central to get some sense of the numbers involved. Overall, direct inclusion of Log4j code in artifacts is not as common as the use of Log4j through dependencies. However, it still adds up to hundreds (~400) of packages which directly include Log4j code, opening these packages to Log4j vulnerabilities. In more than half of all cases (~65%), Log4j code is included as classes directly (i.e. direct inclusion / shading), in contrast to including complete Log4j .jar files (i.e. fat jar), which is typically how it is presented in the remainder of cases. These numbers indicate that tools looking for complete .jar files only will miss most of the cases where Log4j is included directly.

Another interesting metric to investigate is the number of cases where Log4j is included in the artifact, but also as a transitive dependency. There is no direct link between the two notions: code inclusion may result from the requirements of one bundled library, and another may require Log4j as an external dependency. From our observations, in ~30% of the cases where Log4j code is included directly in an artifact as classes and not a complete .jar file, it also does not show up in the transitive dependencies list of the artifact. These cases will not be found by tools that look for explicit mentions of library names in the dependency tree, or the inclusion of complete .jar files.

Recommendations

The JFrog Security Research team is recommending all developers take extra caution and carefully check whether their software products use unpatched versions of Log4j2, both in the first-party code they developed and in the third-party code used in their applications.

We recommend using automated deep scanning tools to accelerate and simplify the detection of the Log4j vulnerability while making sure all possible ways of including Log4j in the released artifacts are covered.

Want to learn more about the Log4j vulnerability and and how it affects you?

Check out these additional resources from the JFrog Security Research Team:
Log4Shell 0-Day Vulnerability: All You Need To Know – Blog
Log4j Log4Shell Vulnerability Explained – Webinar
Log4j Log4Shell Vulnerability Q&A – Blog
Log4j Detection with JFrog OSS Scanning Tools – Blog