Log4j Log4Shell Vulnerability Q&A
In our recent webinar, Log4j Log4Shell Vulnerability Explained: All You Need To Know, our Senior Director Security Research expert Shachar Menashe shared information on the security issue and how to detect and remediate it.
We are happy to share additional information in the following Q&A, based on the questions raised during the webinar.
The Log4j Security Issue
How is the log4j exploit executed?
JFrog published a comprehensive blog post that explains the vulnerability in detail. Please see section: “What causes the Log4j Log4Shell vulnerability?”
I heard the log4j API call was also vulnerable. Why are you only focused on core?
The log4j-api is not vulnerable, only log4j-core is vulnerable.
How does the log4j log4shell vulnerability compare to Shellshock in terms of global impact?
Both log4shell and Shellshock are remote code execution vulnerabilities impacting an enormous range of systems. Shellshock is a vulnerability in bash (a very common Linux shell), which is an application, while log4shell is a vulnerability in the log4j library. For multiple reasons, the log4j security issue poses a bigger challenge in terms of mitigating the threat.
To detect Shellshock, it was enough to check the local system whether a vulnerable version of bash was installed; bash itself is usually not shipped with third-party dependencies.
The log4shell security issue is much harder to detect, since log4j is a library, so detection requires checking all the direct and indirect (transitive / recursive) dependencies. Furthermore, the attack vector for log4shell is more common (logging unsanitized input) than Shellshock’s (passing unsanitized input to bash environment).
Log4shell is also harder to fix – since it is a library, several APIs were changed in newer versions, which means a software vendor might have to modify the first-party code directly interacting with log4j, and not just upgrade log4j itself.
Finally, newer versions of log4j require a newer version of Java (Java 8 vs. the legacy Java 6/7) which means the software vendor might have to upgrade the Java component as well, which may in turn cause incompatibilities with other Java-based software on the system.
What about log4j version 1, which is not vulnerable? Will it be affected by the wave of attention on log4j version 2?
The current exploit does not put version 1 at risk. However, attackers might invest more effort now to research the log4j component to try to find additional vulnerabilities.
Solutions to Find and Fix Log4j
Do you have any specific tools that can help me identify if I have any log4j packages in my repositories?
Yes! To start, our customers using the JFrog DevOps Platform as a central part of their mission-critical software development lifecycle (SDLC) process already have everything needed to quickly remediate against the Log4j vulnerability.
With your accumulated packages, binaries, images, and metadata under Artifactory’s binary repository management, you can search artifacts and builds to discover every usage of the log4j package, including as transitive dependencies, across your entire software supply chain. And you can create Xray policies and watches to block any further builds using vulnerable versions of the log4j package from production.
For the developer community at large, JFrog has also released a helpful set of open source tools to identify log4j use in both source code and binaries in local directories.
Suppose we are using a third-party component which has compile time dependency of log4j. Is there any way we can get rid of log4j while using that component?
This is an issue only if the package uses a vulnerable version of log4j. If this is the case, you would need to get a fixed version of the third-party component. If you have the source code, you can compile it yourself with the fixed log4j version.
Is any dependency that references log4j vulnerable to this attack, even when it uses an API library such as Spring Framework that refers to the log4j library as a dependency?
It depends on the specific case, and which portions of the log4j library are being used. While log4j-core is vulnerable, log4j-api is NOT vulnerable.
For the most comprehensive results, we recommend using a software composition analysis (SCA) scanning tool such as JFrog Xray to identify the vulnerabilities in all of your software dependencies – including those related to log4j, but also many, many more.
If that isn’t available to you, you can use the OSS tools JFrog created for the community to specifically to identify log4j utilization in source code and binaries (see above).
Once Xray detects that an artifact is vulnerable to log4shell, is there a way to determine the consumers of this artifact – i.e., to use Artifactory to track which services/users have accessed/downloaded the vulnerable artifact, so those specific services can be analyzed?
Absolutely! This is what the JFrog Platform was built for. You can use Xray and Artifactory to identify consumers of vulnerable artifacts and control their usage using the following methods:
- Searching your repositories for use of log4j packages
- Searching for CVE-2021-44228
- Running a build-info query in Artifactory to list all the builds that use the log4j-core library as a dependency
- Defining an Xray policy to alert a violation or block download of the vulnerable package
For further details, see our blog post, Your Log4shell Remediation Cookbook Using the JFrog Platform, that discusses multiple methods to discover, block, and fix the log4shell vulnerability.
Can I see a demo of Xray for static and transitive dependency identification?
We will be happy to! Please contact us for a demo of Xray and we will set up a call to show you how you can see through all layers of an artifact’s dependencies.
