CVE-2022-23302

Overview

Apache Log4j is a Java-based logging framework widely adopted for enterprise applications. Prior to its deprecation, Log4j 1.x provided optional components such as JMSSink, enabling log delivery via Java Message Service (JMS) providers.

‍

A deserialization vulnerability (CVE-2022-23302) has been identified in all versions of Log4j 1.x when the framework is configured to use JMSSink. When JMSSink is active, Log4j performs deserialization of data obtained from JNDI lookups based on configuration values supplied by the user or administrator. If an attacker can modify the Log4j configuration file or influence LDAP/JNDI endpoints referenced by that configuration, they can cause JMSSink to load attacker-controlled objects, resulting 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 only affects Log4j 1.x when explicitly configured to use JMSSink, which is not enabled by default. Log4j 1.x reached end-of-life in 2015 and does not receive security updates.

‍

Details

Module Info

• Product: Apache Log4j
• Affected packages: log4j
• Affected versions: >= 1.0.1, <= 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

The vulnerability arises from unsafe deserialization triggered by attacker-controlled JNDI lookups in the JMSSink component. By supplying a malicious TopicConnectionFactoryBindingName value within the Log4j configuration or influencing an LDAP/JNDI service referenced by the configuration, an attacker can force Log4j to deserialize arbitrary objects.

‍

Exploitation of this flaw can result in:

• arbitrary code execution
• remote system compromise
• unauthorized network calls
• execution of attacker-supplied classes

‍

This vulnerability is closely related to CVE-2021-4104, affecting Log4j’s JMSAppender, and demonstrates the broader risks associated with deserialization and JNDI-based resource resolution in Log4j 1.x.

Steps To Reproduce

• Modify the logging configuration to introduce a JMS-based sink that specifies an attacker-controlled LDAP URI as the connection factory binding name.
• Initiate the logging framework to force the component to perform a JNDI lookup, causing the application to request an object from the external directory service.
• Observe the application fetching and executing a remote class file, demonstrating unauthorized remote code execution via the untrusted deserialization of the directory response.

‍

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 configuration using JMSSink
• Upgrade to Log4j 2.x, which provides modern, secure logging functionality
• Avoid JNDI-based configuration patterns

‍