New Log4j Vulnerability CVE-2021-44228: Info and Remediation
Table of Contents
*December 14 update:
While version 2.15.0 was believed to fix the issue, according to CVE-2021-45046, published on Dec. 14, the fix in 2.15.0 was incomplete in some non-default configurations. This new vulnerability may allow attackers to craft malicious input data using a JNDI Lookup pattern which can result in a denial of service (DOS) attack.
The recommendation to mitigate this vulnerability (i.e. set the system property ‘log4j2.noFormatMsgLookup’ to ‘true’) is not applicable. In order to remediate this vulnerability, version 2.16.0 fixes this issue by removing support for message lookup patterns and by disabling JNDI functionality by default.
We recommend upgrading to version 2.16.0 immediately. An alternate solution for releases lower than 2.16.0 involves removing the JndiLookup class from the classpath.
A newly published critical vulnerability in Apache’s widely popular Log4j Java library, CVE-2021-44228 (CVSS score 10) was published over the weekend, causing a lot of concern.
What you need to know about the Log4j vulnerability
Also known as Log4shell, Apache’s Log4j security update explains that in versions 2.14.1 and under of the library, JNDI features used in configuration, log messages, and parameters, do not protect against attacker-controlled LDAP and other JNDI related endpoints.
This allows attackers that gain control over log messages or log message parameters to execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. Since it was discovered, Apache quickly fixed this issue, and released log4j version 2.15.0, where this behavior has been disabled by default. Since then, On December 14, CVE-2021-45046 was published, announcing that this fix was incomplete, and recommending to update to version 2.16.0 to ensure that CVE-2021-44228 is remediated.
This issue is particularly concerning because of how widely used this open source library is, supporting millions of Java applications to log error messages. According to Symantec, exploit attempts have already been detected in the wild, with exploit code being shared publicly and multiple attackers are already attempting to exploit it.
Remediating the Log4j vulnerability
As is often the case with open source dependencies, and is ubiquitous across open source and third-party applications, meaning that the vulnerable library is most probably used by many applications in our codebases.
In terms of remediation, the first step is to scan your applications to check whether you are using vulnerable Log4j versions under 2.16.0. If a vulnerable version is detected, update to fixed version 2.16.0 to avoid an exploit.
Since the December 14 publication of CVE-2021-45046, these are the updated remediation recommendations:
Log4j 1.x mitigation: Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability.
To mitigate, audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.
Log4j 2.x mitigation: Implement one of the mitigation techniques below.
- Java 8 (or later) users should upgrade to release 2.16.0.
- Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available.
- Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
Fixing open source security vulnerabilities early
This is not the first or last time a vulnerability will be disclosed and discovered in the wild. Integrating Mend into your IDE, Repo, or CI tools can save your development, DevOps, and security teams a lot of time, by automatically detecting, alerting, and remediating issues early in development.
Our recommendation is to perform the following steps, using Mend capabilities, to quickly address this new critical vulnerability:
- Run a scan to determine whether you are using a vulnerable Log4j version:
If you have already set Mend policies for high severity vulnerability alerts, Mend will notify you (as per your alert configuration) in case you are affected by this vulnerability via a direct or indirect dependency to this library.
If you don’t have policies set for high severity vulnerabilities, you can check the vulnerability report directly from the UI to determine the impact to your products or projects.
For any other projects that you have not previously scanned with Mend (primarily Java-based), we recommend that you run a full scan on those as soon as possible.
- Use Mend Prioritize to determine whether the vulnerable function actually impacts your code. If it doesn’t, you are at lower risk.
- Enable Mend Remediate in your code repository so that if a vulnerable version is detected, an automated update to the secure version is provided
Get free tools to detect and fix Log4j vulnerabilities: Learn about our free CLI tool, or download it now.
Using Mend’s AppSec tools to quickly remediate issues before they make headlines, will save everyone in your organization valuable resources, and allow you to continue to use open source components with confidence, and your customers’ trust.
