How to detect the Log4j vulnerability in your applications

Yesterday the Apache Foundation 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 you have Log4j hiding somewhere in your 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 you build your Java application. 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 your application. In some situations, one dependency pulls in hundreds of other dependencies making it even more difficult to find.

Essentially, in the Java world, you 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 your 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.

Anchore

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 you deliver. 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 your Java applications.

Grype is a scanner that has the ability to tell us which specific vulnerabilities our software contains. When you include a dependency in your application you 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 you 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.

Anchore

Syft and Grype have the ability to scan your applications no matter where they reside. You can scan a directory on disk, scan a container image locally, or even scan a container in a remote registry. You can scan source code before building, or the final application after it’s built. It’s important to scan your 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 you didn’t pick up a critical Log4j vulnerability last week, but you might this week!

Keep Syft and Grype handy

Any time a new zero-day vulnerability is discovered, it can be difficult and challenging for impacted organizations to remediate the problem quickly. The first and most important step is to understand if a particular vulnerability even affects you, and in the case of JAR files it can be a challenge to understand this without tooling. Anchore’s open source Grype and Syft tools dig all the way to the bottom of your dependency tree to identify if there’s a copy of Log4j hiding somewhere.

As an industry, how we react and support each other during zero-day vulnerabilities is critical. Now is the time to share solutions and awareness to help prevent breaches like this in the coming years.

Josh Bressers is VP of security at Anchore.

—

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.