What’s Log4j? What is it used for?
Log4j is a popular Java logging library widely used in many Java enterprise applications. Because logging is so fundamental to every application, the impact of the Log4j vulnerability is quite broad. More likely than not, this vulnerability impacts you if you have Java code embedded in your software stack.
In this article, we’ll take a look at how you can scan your container images for Log4j by running a Software Bill of Materials (SBOM) scan using Syft.
CVE-2021-44228 (Apache Log4j Remote Code Execution)
The Log4j vulnerability allows attackers to perform a remote code execution attack and compromise The Log4j vulnerability allows attackers to perform a remote code execution attack and compromise affected systems. The NIST website describes this vulnerability in greater detail: https://nvd.nist.gov/vuln/detail/CVE-2021-44228.
If you’re interested in learning how the exploit code works, detailed proof of concept is available at the following GitHub repository: https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce.
Exposure of container images, the base image problem
With the advent of microservices, it is not uncommon for software deployed as containers to use many other containers as dependent services. This means that if you have a service you are consuming as a dependency that is shipped as a Docker container, you have potential exposure to the Log4j vulnerability.
Also, application developers frequently use existing container images from Docker Hub as base images for building their custom images. All derived images are vulnerable if the base image is impacted by a core library such as Log4j.
Understanding your Software Bill of Materials (SBOM)
We will use a popular open-source tool, Syft, to understand the Software Bill of Materials (SBOM) inside a container image. Let’s start with a simple image like an Alpine Linux container. Running Syft on it is simple and instantly gives you the Alpine container image components.
$ syft alpine
New version of syft is available: 0.32.2
✔ Pulled image
✔ Loaded image
✔ Parsed image
✔ Cataloged packages [14 packages]
NAME VERSION TYPE
alpine-baselayout 3.2.0-r18 apk
alpine-keys 2.4-r1 apk
apk-tools 2.12.7-r3 apk
busybox 1.34.1-r3 apk
ca-certificates-bundle 20191127-r7 apk
libc-utils 0.7.2-r3 apk
libcrypto1.1 1.1.1l-r7 apk
libretls 3.3.4-r2 apk
libssl1.1 1.1.1l-r7 apk
musl 1.2.2-r7 apk
musl-utils 1.2.2-r7 apk
scanelf 1.3.3-r0 apk
ssl_client 1.34.1-r3 apk
zlib 1.2.11-r3 apkLooking for Log4j in your container images
We’ll now use Syft to scan a container image that we think may be impacted. Let’s start with a JBoss image. JBoss is a popular Java middleware used widely in several applications. We’ll use the jboss/wildfly application server image in this demo and run a Syft SBOM scan. We will then grep for log4j to find any matches in the scan results.
$ syft jboss/wildfly|grep log4
New version of syft is available: 0.32.2
✔ Loaded image
✔ Parsed image
✔ Cataloged packages [1152 packages]
log4j-api 2.14.1 java-archive
log4j-jboss-logmanager 1.2.2.Final java-archive
log4j2-jboss-logmanager 1.0.0.Final java-archiveCVE-2021-44228 currently impacts all versions of Log4j 2.x <= 2.14.1. As you can see from the scan results above, the Docker Hub image for the JBoss/WildFly container is currently vulnerable to the RCE exploit.
The exposure radius of this exploit is huge and flagged as critical by the NIST’s vulnerability database. Since container images are layered and built from existing images, an attacker can easily exploit all images derived from a vulnerable image.
How secure are your containers? It’s easy to find this out, but you mustn’t skip this as part of your software delivery process. Get an inventory of your software components with every build and stay on top of all potential exploits and vulnerabilities.
In the next article on the Log4j vulnerability, we will see how we can detect potential attacks being run on your enterprise using LogFlow‘s security rules to catch malicious attempts.
