Credit: Dreamstime
The Apache Foundation recently released an emergency update for a critical zero-day vulnerability in Log4j, a ubiquitous logging tool included in almost every Java application. The issue has been named Log4Shell and received the identifier CVE-2021-44228.
The problem revolves around a bug in the Log4j library that can allow an attacker to execute arbitrary code on a system that is using Log4j to write out log messages. This security vulnerability has a broad impact and is something anyone with an application containing Log4j needs to immediately pay attention to.
Why addressing Log4Shell is a major challenge
Log4j is a library that is used by many Java applications. It’s one of the most pervasive Java libraries to date. Most Java applications log data, and there’s nothing that makes this easier than Log4j.
The challenge here is finding Log4j because of the way Java packaging works. It’s possible users have Log4j hiding somewhere in their application and don’t even know it.
In the Java ecosystem, dependencies are distributed as Java archive (JAR) files, which are packages that can be used as a Java library. Commonly used tools, such as Maven and Gradle, can automatically add JAR files as users build Java applications.
It’s also possible for a JAR to contain another JAR to satisfy a dependency, which means a vulnerability can be hidden several levels down in an application. In some situations, one dependency pulls in hundreds of other dependencies making it even more difficult to find.
Essentially, in the Java world, users can have a JAR nested in a JAR nested in a JAR. This creates many layers that all need to be investigated. Just looking at the JARs a project pulls in directly may not be enough, since Log4j could be hiding inside of another JAR file.
Scan for Log4j with open source tools
There are two open source tools led by Anchore that have the ability to scan a large number of packaged dependency formats, identify their existence, and report if they contain vulnerabilities. In this case being able to scan JAR files, especially nested layers of JAR files, is what we want.
Syft generates a software bill of materials (SBOM) and Grype is a vulnerability scanner. Both of these tools are able to inspect multiple nested layers of JAR archives to uncover and identify versions of Log4j.
Syft is also able to discern which version of Log4j a Java application contains. The Log4j JAR can be directly included in our project, or it can be hidden away in one of the dependencies we include. For example, using Syft to scan this sample Java project shows that it includes Log4j version 2.14.1, which is vulnerable to Log4Shell.
Regardless of the version of Log4j that is included, there is value in generating and storing an SBOM to keep a record of everything that is included in any software component or application that is delivered. When a new vulnerability is found, such as Log4Shell, it’s much faster to search through a repository of SBOMs than it is to find and scan all of the Java applications.
Grype is a scanner that has the ability to tell us which specific vulnerabilities software contains. When users include a dependency in an application they can also identify the vulnerabilities that the dependency contains, and so on through multiple levels of nesting.
Grype can scan the software directly, or scan the SBOM produced by Syft. This allows users to re-scan the SBOM for new vulnerabilities even after the software has been deployed or delivered to customers.
Scanning the same sample Java project with Grype finds the Log4j vulnerability and identifies it as a critical severity.
Syft and Grype have the ability to scan applications no matter where they reside. Users can scan a directory on disk, scan a container image locally, or even scan a container in a remote registry. They can also scan source code before building, or the final application after it’s built.
It’s important to scan applications during every stage of development, just because a source code scan is clean doesn’t mean the final build will be. Even scanning after deployment is a good idea. Maybe users didn’t pick up a critical Log4j vulnerability last week, but they might this week.
