Apache Log4j Security Vulnerabilities

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

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

• CVE-2021-44832

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

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

• CVE-2021-45105
• LOG4J2-3230

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

History

Severity is now Critical

The original severity of this CVE was rated as Moderate; since this CVE was published security experts found additional exploits against the Log4j 2.15.0 release, that could lead to information leaks, RCE (remote code execution) and LCE (local code execution) attacks.

Base CVSS Score changed from 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) to 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).

The title of this CVE was changed from mentioning Denial of Service attacks to mentioning Remote Code Execution attacks.

Only Pattern Layouts with a Context Lookup (for example, $${ctx:loginId}) are vulnerable to this. This page previously incorrectly mentioned that Thread Context Map pattern (%X, %mdc, or %MDC) in the layout would also allow this vulnerability.

While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to localhost by default, there are ways to bypass this and users should not rely on this.

Older (discredited) mitigation measures

This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open.

Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.

The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.

The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.

Release Details

From version 2.16.0 (for Java 8), the message lookups feature has been completely removed. Lookups in configuration still work. Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in configuration now need to be enabled explicitly. 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.

From version 2.12.2 (for Java 7) and 2.3.1 (for Java 6), the message lookups feature has been completely removed. Lookups in configuration still work. Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in configuration now need to be enabled explicitly. When enabled, JNDI will only support the JAVA protocol, support for the LDAP protocol has been removed.

From version 2.17.0 (for Java 8), support for the LDAP protocol has been removed and only the JAVA protocol is supported in JNDI connections.

From version 2.17.0 (for Java 8), 2.12.3 (for Java 7) and 2.3.1 (for Java 6), the property to enable JNDI has been renamed from ‘log4j2.enableJndi’ to three separate properties: ‘log4j2.enableJndiLookup’, ‘log4j2.enableJndiJms’, and ‘log4j2.enableJndiContextSelector’.

Work in progress

The Log4j team will continue to actively update this page as more information becomes known.

Credit

This issue was discovered by Kai Mindermann of iC Consult and separately by 4ra1n.

Additional vulnerability details discovered independently by Ash Fox of Google, Alvaro Muñoz and Tony Torralba from GitHub, Anthony Weems of Praetorian, and RyotaK (@ryotkak).

References

• CVE-2021-45046
• LOG4J2-3221

Description

In Apache Log4j2 versions up to and including 2.14.1 (excluding security releases 2.3.1, 2.12.2 and 2.12.3), the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

Mitigation

History

Work in progress

The Log4j team will continue to actively update this page as more information becomes known.

Credit

This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.

References

• https://issues.apache.org/jira/browse/LOG4J2-3201
• https://issues.apache.org/jira/browse/LOG4J2-3198.

Description

Improper validation of certificate with host mismatch in Log4j2 SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender.

The reported issue was caused by an error in SslConfiguration. Any element using SslConfiguration in the Log4j Configuration is also affected by this issue. This includes HttpAppender, SocketAppender, and SyslogAppender. Usages of SslConfiguration that are configured via system properties are not affected.

Mitigation

Users should upgrade to Apache Log4j 2.13.2 which fixed this issue in https://issues.apache.org/jira/browse/LOG4J2-2819 by making SSL settings configurable for SMTPS mail sessions. As a workaround for previous releases, users can set the mail.smtp.ssl.checkserveridentity system property to true to enable SMTPS hostname verification for all SMTPS mail sessions.

Credit

This issues was discovered by Peter Stöckli.

References

• CVE-2020-9488
• LOG4J2-2819

Description

When using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.

Mitigation

Java 7 and above users should migrate to version 2.8.2 or avoid using the socket server classes. Java 6 users should avoid using the TCP or UDP socket server classes, or they can manually backport the security fix commit from 2.8.2.

Credit

This issue was discovered by Marcio Almeida de Macedo of Red Team at Telstra

References

• CVE-2017-5645
• LOG4J2-1863
• Security fix commit

Critical

A vulnerability rated with a Critical impact is one which could potentially be exploited by a remote attacker to get Log4j to execute arbitrary code (either as the user the server is running as, or root). These are the sorts of vulnerabilities that could be exploited automatically by worms. Critical vulnerabilities score between 9.0 and 10.0 on the CVSS v3 calculator.

High

A vulnerability rated as High impact is one which could result in the compromise of data or availability of the server. For Log4j this includes issues that allow an easy remote denial of service (something that is out of proportion to the attack or with a lasting consequence), access to arbitrary files outside of the context root, or access to files that should be otherwise prevented by limits or authentication. High vulnerabilities score between 7.0 and 8.9 on the CVSS v3 calculator.

Moderate

A vulnerability is likely to be rated as Moderate if there is significant mitigation to make the issue less of an impact. This might be because the flaw does not affect likely configurations, or it is a configuration that isn’t widely used. Moderate vulnerabilities score between 4.0 and 6.9 on the CVSS v3 calculator.

Low

All other security flaws are classed as a Low impact. This rating is used for issues that are believed to be extremely hard to exploit, or where an exploit gives minimal consequences. Low vulnerabilities score between 0.1 and 3.9 on the CVSS v3 calculator.