Log4Shell Part 1: Answering FAQs on the Log4Shell Security Vulnerability
By Jesse Gorzinski / December 14, 2021
Jesse Gorzinksi on the Log4Shell security vulnerability, what it impacts and how to remediate the problem in Java programs
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.
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
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!
Tagged as:
AIX / IBM i / Linux on POWER / Article / Security / Systems management / Application development / Open source / Open source on IBM i / Data security / Java / Open Your i blog
About the author
Jesse Gorzinski is the business architect of open source technologies.
See more by Jesse Gorzinski