This page lists all the security vulnerabilities fixed in released versions of Apache Log4j 2. Each vulnerability is given a security impact rating by the Apache Logging security team. Note that this rating may vary from platform to platform. We also list the versions of Apache Log4j the flaw is known to affect, and where a flaw has not been verified list the version with a question mark.
Log4j 1.x has reached End of Life in 2015 and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.
Binary patches are never provided. If you need to apply a source code patch,
use the building instructions for the Apache Log4j version that you are using.
For Log4j 2 these can be found in BUILDING.md located in the root subdirectory of the source distribution.
If you need help on building or configuring Log4j or other help on following the instructions to mitigate the known vulnerabilities listed here, please subscribe to, and send your questions to the public Log4j Users mailing list.
If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the Log4j Security Team. Thank you!
Fixed in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6)
CVE-2021-44832: Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration.
| CVE-2021-44832 | Remote Code Execution |
|---|---|
| Severity | Moderate |
| Base CVSS Score | 6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H) |
| Versions Affected | All versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4 |
Description
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
Mitigation
Log4j 1.x mitigation
Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation
Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).
In prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.
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.
Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.
Release Details
From version 2.17.1, (and 2.12.4 and 2.3.2 for Java 7 and Java 6),
the JDBC Appender will use JndiManager and will require the log4j2.enableJndiJdbc system property to contain
a value of true for JNDI to be enabled.
The property to enable JNDI has been renamed from ‘log4j2.enableJndi’
to three separate properties: log4j2.enableJndiLookup, log4j2.enableJndiJms, and log4j2.enableJndiContextSelector.
JNDI functionality has been hardened in these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, support for the LDAP protocol has been removed and only the JAVA protocol is supported in JNDI connections.
Work in progress
The Log4j team will continue to actively update this page as more information becomes known.
Credit
No credit is being awarded for this issue.
References
Fixed in Log4j 2.17.0 (Java 8), 2.12.3 (Java 7) and 2.3.1 (Java 6)
CVE-2021-45105: Apache Log4j2 does not always protect from infinite recursion in lookup evaluation
| CVE-2021-45105 | Denial of Service |
|---|---|
| Severity | Moderate |
| Base CVSS Score | 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) |
| Versions Affected | All versions from 2.0-beta9 to 2.16.0, excluding 2.12.3 |
Description
Apache Log4j2 versions 2.0-alpha1 through 2.16.0, excluding 2.12.3,
did not protect from uncontrolled recursion from self-referential
lookups.
When the logging configuration uses a non-default Pattern Layout with a
Context Lookup (for example, $${ctx:loginId}),
attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup,
resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.
Mitigation
Log4j 1.x mitigation
Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation
Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
Alternatively, this infinite recursion issue can be mitigated in configuration:
- In PatternLayout in the logging configuration, replace Context Lookups like
${ctx:loginId}or$${ctx:loginId}with Thread Context Map patterns (%X, %mdc, or %MDC). - Otherwise, in the configuration, remove references to Context Lookups like
${ctx:loginId}or$${ctx:loginId}where they originate from sources external to the application such as HTTP headers or user input.
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.
Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.
Release Details
From version 2.17.0, (and 2.12.3 and 2.3.1 for Java 7 and Java 6), only lookup strings in configuration are expanded recursively; in any other usage, only the top-level lookup is resolved, and any nested lookups are not resolved.
The property to enable JNDI has been renamed from ‘log4j2.enableJndi’ to three separate properties: ‘log4j2.enableJndiLookup’, ‘log4j2.enableJndiJms’, and ‘log4j2.enableJndiContextSelector’.
JNDI functionality has been hardened in these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, support for the LDAP protocol has been removed and only the JAVA protocol is supported in JNDI connections.
Work in progress
The Log4j team will continue to actively update this page as more information becomes known.
Credit
Independently discovered by Hideki Okamoto of Akamai Technologies, Guy Lederfein of Trend Micro Research working with Trend Micro’s Zero Day Initiative, and another anonymous vulnerability researcher.
References
Fixed in Log4j 2.16.0 (Java 8) and Log4j 2.12.2 (Java 7)
CVE-2021-45046: Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations
| CVE-2021-45046 | Remote Code Execution |
|---|---|
| Severity | Critical |
| Base CVSS Score | 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) |
| Versions Affected | All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 |
Description
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on MacOS, Fedora, Arch Linux, and Alpine Linux.
Mitigation
Log4j 1.x mitigation
Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation
Implement one of the following mitigation techniques:
- Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
- Otherwise, in any release other than 2.16.0, you may remove the
JndiLookupclass from the classpath:zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Users are advised not to enable JNDI in Log4j 2.16.0, since it still allows LDAP connections. If the JMS Appender is required, use one of these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, only the JAVA protocol is supported in JNDI connections.
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.
Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.
No comments:
Post a Comment