Log4j RCE - An analysis and comparison of Software Composition Analysis tools in the market

Over the weekend, a Remote Code Execution (RCE) vulnerability was detected in a widely used open source component - log4j. In response to this disclosure, security teams all over the world have been scrambling to patch the RCE vulnerability in their systems and applications. The RCE vulnerability identified is named CVE-2021-44228 and affects all versions of the log4j library between 2.0 to 2.14.1 and log4j-2.15.0-rc1. Scantist has identified the vulnerability-free version to be log4j-2.15.0-rc2. (Github recommended the fix version to be log4j-2.15.0-rc2, while Maven released the version log4j-2.15.0 on the basis of log4j-2.15.0-rc2).

CVE-2021-44228 is a significant disclosure in the open source software security space as log4j is widely used by developers who use Java (log4j is introduced into the application using both direct and transitive dependencies). Due to its ubiquity, manually identifying if log4j is being used in applications is a virtually impossible task for development teams to carry out. Software Composition Analysis (SCA) offers a simple solution to this problem that development and security teams are facing.

The research team at Scantist did a comparison of Software Composition Analysis (SCA) tools within the market to identify if these tools were able to identify and provide targeted remediation for CVE-2021-44228. We found that many tools in the market were unable to identify CVE-2021-44228 correctly due to the following challenges.

Unable to identify the sub-components affected by CVE-2021-44228

The actual vulnerability exists in the log4j-core sub-component and general, untargeted fixes that do not patch the log4j-core sub-component may not be able to fix CVE-2021-44228. Many SCA tools in the market provided untargeted remediation advice and were unable to apply a patch that would result in the removal of the vulnerability.

There are many sub-components that exist within org.apache.logging.log4j, for example log4j-api, log4j-slf4j-impl etc. Many of the tools that we tested identified other components as vulnerable due to CVE-2021-44228, causing unwanted noise and false positives that increases the development team’s workload.

Unable to Scan Both Source Code and Binary Scans

The tools available in the market that can identify CVE-2021-44228 typically are unable to scan the Binary format of Java program (e.g., in the form of JAR files) on the same platform. We believe that a combination of both modes of scanning is crucial as source code scanning helps identify if log4j-core component is a direct or transitive dependency, while the binary scans help identify the log4j-core component in a compiled jar or class file.

Scantist SCA provides both binary and source code scanning to identify vulnerable components like log4j-core in applications.

Log4j as a Transitive Dependency

Log4j may exist as a vulnerable transitive component that is called by a root-level dependency, like MyBaits. While there are websites that list components that use log4j as a transitive dependency, the lists are often incomprehensive. To fully minimise the damage brought about by using log4j, the development teams must have an accurate dependency chart of the applications they build. Many tools in the market often miss out on transitive dependencies, resulting in development teams being unable to fully mitigate the impact of vulnerabilities in these open source libraries.

Many tools that are available in the market are unable to accurately identify transitive dependencies and their versions via source code scanning. On the other hand, tools that provide binary scanning are unable to accurately identify log4j in applications as they require the actual log4jcore.jar, or equivalent class files, to be stored within the binary file. This happens as log4j-core.jar may be used by other components within the production environment as a transitive dependency, but not stored within the jar file itself. As a result, the tools are unable to identify the CVE-2021-44228 present in applications.

Binary Analysis

Under specific circumstances, log4j can be introduced into the application by a compiled jar version to detect log4j, hence the SCA tool an organisation uses must have the capability to conduct a jar binary file analysis. During the deployment process of the jar file, shadow jars present within the jar file may affect the binary analysis results of the SCA tool. As such, the SCA tool must be able to conduct signature matching to correctly identify the log4j component.

We analysed the SCA tools that are available in the market and found that these tools can only support either source code analysis or binary, but not both on the same platform. The result is that these tools provide a high percentage of false negatives and false positives, which leads to the development teams wasting their precious manhours in fixing what is unnecessary but increasing their risk exposure while missing out vulnerable components.

Scantist SCA helps development and security teams accurately identify vulnerable dependencies with our source code analysis and binary analysis scans, providing the best protection for our users against open source vulnerabilities. Scantist also collects all available package managers and data of maven to provide our users the most accurate dependency analysis.

Scantist uses a proprietary fuzzy hash algorithm based on CFG to identify Java-based binaries via signature matching. The signature matching increases the chances of identifying even open source components that have been modified or customized to the organisation’s needs.

Using Scantist SCA for your application security testing

Scantist SCA can help your teams manage your open source components and identify the associated vulnerabilities effectively. By combining source code and binary analysis, Scantist SCA helps organisations take a proactive stance in managing open source vulnerabilities.

Scantist SCA responded quickly to the Log4j2 vulnerability, providing swift and accurate detection and support for the CVE-2021-44228 vulnerability.

--------

To find out if you are using log4j in your applications, you can follow these three simple steps:

1. Create an account at www.scantist.io

2. Connect your repositories with Scantist SCA

3. Click on 'scan'

4. After scanning, click on the scanned project to identify the list of open source dependencies

If you'd like a technical person to walk you through the scanning, we'll be happy to get on a quick 15 minutes call with you to help you with your first scans.