CVE-2021-4104

Overview

Apache Log4j is a Java-based logging framework that provides flexible logging capabilities for enterprise applications. Its plugin architecture and configuration options made it a popular choice for JVM-based systems for many years, particularly before the introduction of Log4j 2.x.

‍

A remote code execution vulnerability (CVE-2021-4104) has been identified in Apache Log4j 1.x, specifically within the JMSAppender component. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution

‍

Per OWASP: Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application. This type of attack exploits poor handling of untrusted data. These types of attacks are usually made possible due to a lack of proper input/output data validation.

‍

This issue affects all Log4j 1.2 versions but only when JMSAppender is explicitly enabled, which is not the default configuration, and is considered a high security risk.

‍

Details

Module Info

• Product: Apache Log4j
• Affected packages: log4j
• Affected versions: >= 1.2, <= 1.2.17
• GitHub repository: https://github.com/apache/logging-log4j1
• Published packages: https://central.sonatype.com/artifact/log4j/log4j
• Package manager: Maven
• Fixed In: NES for Apache Log4j v1.2.18

‍

Vulnerability Info

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

Steps To Reproduce

• Deploy an external directory service configured to return a reference to a remote object factory upon a specific naming request.
• Instantiate a messaging-based appender within the Log4j environment, supplying it with a resource identifier that points to the prepared directory service.
• Execute the application with the appropriate system property enabled to allow the resolution of remote object classes, thereby triggering the loading and execution of the secondary payload.

‍

Mitigation

Apache Log4j 1.x has been end-of-life since 2015 and no longer receives community updates. Users of the affected component should apply one of the following mitigations:

‍

Users of Log4j 1.x should apply the following mitigations:

‍

• Upgrade affected applications to supported versions of Log4j
• Leverage a commercial support partner like HeroDevs for post-EOL security support
• Remove or disable JMSAppender from Log4j configurations
• Upgrade to Log4j 2.x, which resolves this and other known security issues

‍