Log4Shell Part 1: Answering FAQs on the Log4Shell Security Vulnerability

Jesse Gorzinski December 14, 2021

You’ve likely heard of the Log4Shell (aka “LogJam”) security vulnerability that was recently published. It has gotten a lot of press, and understandably so; it can be easy to exploit, and it can allow an attacker to perform remote code execution. You definitely shouldn’t ignore this one!

To help you understand what this means, I’ve written a two-part series. Today, in Part 1, I will provide answers to a few of the commonly-asked questions I have received.

Q: Where can I find the official documentation on this vulnerability?

The vulnerability has been assigned an ID of CVE-2021-44228. As with most security vulnerabilities, it’s recorded in the National Vulerability Database (NVD). The official documentation at NVD can be found here.

Q: What OSes does the Log4Shell vulnerability affect?

This is a Java vulnerability, so it impacts Java applications running on any OS. It does not impact any particular OS per se, just the Java programs running within.

Q: How should I remediate the problem in my Java programs?

You should look to remediate the Log4Shell vulnerability in any of your own Java applications running on the system. Follow these steps:

Step 1: Disable Log4J lookup functionality

For versions of log4j >= 2.10, you can disable the Log4J lookup functionality by setting a Java system property, “log4j2.formatMsgNoLookups” to “true”. Alternatively, you can use the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable. On IBM i, that can be done with ADDENVVAR:

ADDENVVAR ENVVAR(LOG4J_FORMAT_MSG_NO_LOOKUPS) VALUE('true') REPLACE(*YES) LEVEL(*SYS)

I have also written a small shell script that can apply this stopgap (and incomplete) remediation.

When that environment variable is set, Log4J versions 2.10.0 or newer will not have this vulnerability. For reference, 2.10 was first released in November 2017. Optimistically, any applications built or updated since then will run 2.10 and are therefore safe if the lookup functionality is disabled.

Setting LOG4J_FORMAT_MSG_NO_LOOKUPS is unlikely to be disruptive and is a good caution to have in place while you pursue other remediation.

Step 2: Locate usage of Log4J in your applications

If you keep a diligent inventory of what open-source software your applications are using, that’s great! Otherwise, make a best effort to locate instances of Log4j on your system. My colleague, Scott Forstie, recently published some SQL (here) that can locate all files with “log4j” in the name. Alternatively, one can install the “findutils” package and leverage the “updatedb” and “locate” packages. This is a great start, but it does have its caveats:

It can turn up false positives, for instance the Log4j to SLF4J adapter could be named “slf4j-log4j12-1.7.25.jar.” You are most interested in files within the format “log4j-<version>.jar” or “log4j-core-<version>.jar.”
It cannot find instances of Log4j that are embedded within some other form of archive. For instance, if a web application is deployed in a web archive (.WAR) file, this scan will not find it. You may want to modify the query to look for file types you know may be of interest, so that you can discover Java programs that need more scrutiny.

The most comprehensive analysis involves the investigation of all of your Java programs and their dependencies. You may be thinking “but I don’t know what’s running!” Certainly, though, you should know what production workloads are running on the system and where they are located. WRKJVMJOB can help, too. That’s the best place to start! Your production workloads represent the primary attack vector for external hackers.

Step 3: Upgrade Log4J

Certainly, upgrading Log4J to version 2.16.0 (or newer) is the best option. Since Log4J uses semantic versioning, upgrading from other 2.x versions should be a low-risk operation.

Q: What about Java programs that aren’t “mine?”

For IBM impacts from this vulnerability, please see this blog post on the most up-to-date information regarding IBM products and services, including any exposures and remediation steps. For any third-party software that uses Java, contact the software vendor for information.

Q: Should I be freaking out about this security vulnerability?

Certainly, security vulnerabilities such as this can be frightening. As I mentioned earlier, if an application is truly exposed, it can be easily attacked by a malicious entity. When assessing your security posture, keep in mind that for an attacker to exploit Log4Shell, all of the following must be true:

The application must be running a vulnerable version of Log4J
An attacker must be able to feed data that will be directly logged by the application
Your application must be able to create a new outbound connection to a malicious server

Plus, using a vulnerable version of the library isn’t enough for an exploitation. For instance, if the Log4J library is not used to log things that an attacker can inject (HTTP request headers, chat messages, etc.), then the risk is averted. On IBM i, for instance, many applications use the Apache HTTP server to log HTTP request data, not a back-end Java application. The Apache HTTP server isn’t written in Java and is therefore not exposed here. However, since such assessments are difficult to make, you should still analyze your software stack and keep current on patches like the Log4J update.

Q: What can be learned from this?

Open-source software is a necessity, but it requires proper due diligence in risk assessment, currency plans, mitigation strategies and more. The Log4Shell vulnerability enforces some key best practices for managing open-source software. In Part 2, I discuss some techniques that can keep your organization’s software secure and future-proof!