CVE-2021-45105: Apache Log4j DoS Vulnerability

CVE-2021-45105 Overview

Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) contain a vulnerability that fails to protect against uncontrolled recursion from self-referential lookups. This flaw allows an attacker with control over Thread Context Map (MDC) data to cause a denial of service when a specially crafted string is interpreted by the logging framework. This vulnerability is part of the broader Log4Shell vulnerability series that impacted organizations globally during December 2021.

Critical Impact

Attackers can crash Java applications using vulnerable Log4j2 versions by injecting self-referential lookup strings, causing stack overflow through infinite recursion and resulting in application denial of service.

Affected Products

• Apache Log4j 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1)
• Oracle WebLogic Server 12.2.1.3.0, 12.2.1.4.0, and 14.1.1.0.0
• Oracle Communications products (multiple versions including Diameter Signaling Router, Session Route Manager, and others)
• Oracle Enterprise Manager Base Platform 13.4.0.0 and 13.5.0.0
• Oracle PeopleSoft Enterprise PeopleTools 8.58 and 8.59
• NetApp Cloud Manager
• Debian Linux 10.0 and 11.0
• SonicWall Email Security, Network Security Manager, and Web Application Firewall

Discovery Timeline

• 2021-12-18 - CVE-2021-45105 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-45105

Vulnerability Analysis

This vulnerability stems from improper input validation (CWE-20) in Apache Log4j2's lookup functionality. The logging framework provides powerful string substitution capabilities through lookups, which allow dynamic content to be resolved at runtime. When processing log messages containing lookup patterns like ${ctx:key}, Log4j2 resolves these references by examining the Thread Context Map.

The vulnerability manifests when an attacker can influence the Thread Context Map data with values containing self-referential lookups. When Log4j2 attempts to process such a lookup, it enters an infinite recursion loop as each lookup resolution triggers another lookup resolution, eventually exhausting the stack and causing the application to crash with a StackOverflowError.

While this vulnerability requires high attack complexity due to the need to control Thread Context Map data, it can be exploited over the network without authentication or user interaction, making it a significant concern for internet-facing applications.

Root Cause

The root cause is the lack of recursion depth protection in Log4j2's lookup resolution mechanism. When evaluating string interpolation patterns in log messages, the StrSubstitutor class did not implement safeguards against circular references or self-referential lookup chains. This allows malicious input to create infinite recursion scenarios.

The vulnerability specifically affects how Log4j2 handles context lookups (${ctx:...}), where an attacker can set a context value that references itself or creates a lookup chain that ultimately loops back, triggering unbounded recursion.

Attack Vector

The attack requires an attacker to have some level of control over data that gets placed into the Thread Context Map (also known as MDC - Mapped Diagnostic Context). This is commonly achieved through:

1. HTTP request headers that applications log (e.g., User-Agent, X-Forwarded-For)
2. User-supplied input fields that are logged for diagnostic purposes
3. Query parameters or form data that enters the logging pipeline
4. Authentication tokens or session identifiers included in log messages

When the application logs a message that triggers the self-referential lookup resolution, the Java process experiences a stack overflow and crashes. The attack can be repeated to maintain a persistent denial of service condition against the target application.

The exploitation pattern involves injecting a payload such as ${${ctx:key}} where the context key key is set to a value that creates infinite recursion. This causes the lookup resolver to repeatedly attempt resolution until the JVM stack is exhausted.

Detection Methods for CVE-2021-45105

Indicators of Compromise

• Unexpected application crashes with java.lang.StackOverflowError in Log4j2-related stack traces
• Repetitive application restarts due to JVM crashes in logging components
• Log entries containing nested lookup patterns like ${ctx:${ctx:...}} or similar recursive structures
• HTTP requests with suspicious recursive patterns in headers or parameters that are subsequently logged

Detection Strategies

• Monitor Java applications for frequent StackOverflowError exceptions originating from org.apache.logging.log4j classes
• Implement web application firewall rules to detect and block requests containing nested ${...} patterns in headers and parameters
• Scan application dependencies to identify Log4j2 versions between 2.0-alpha1 and 2.16.0 using software composition analysis tools
• Review application logs for evidence of lookup recursion attempts or malformed context variable references

Monitoring Recommendations

• Configure JVM monitoring to alert on repeated StackOverflowError exceptions within short time windows
• Enable detailed access logging to capture HTTP request headers and parameters for forensic analysis
• Implement application performance monitoring to detect abnormal restart patterns indicating DoS attacks
• Set up dependency scanning in CI/CD pipelines to flag vulnerable Log4j2 versions before deployment

How to Mitigate CVE-2021-45105

Immediate Actions Required

• Upgrade Apache Log4j2 to version 2.17.0 or later for Java 8+, version 2.12.3 for Java 7, or version 2.3.1 for Java 6
• If immediate upgrade is not possible, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• Review all applications in your environment for Log4j2 usage, including transitive dependencies
• Implement input validation to sanitize user-controlled data before it enters the Thread Context Map

Patch Information

Apache addressed this vulnerability in Log4j 2.17.0 (for Java 8+), 2.12.3 (for Java 7), and 2.3.1 (for Java 6). The fix implements recursion depth limits in the lookup substitution logic to prevent infinite loops. Organizations should consult vendor-specific advisories for downstream products:

• Apache Log4j Security Documentation
• Oracle Security Alert CPU January 2022
• Oracle Security Alert CPU April 2022
• Debian Security Advisory DSA-5024
• NetApp Security Advisory NTAP-20211218-0001
• Cisco Security Advisory - Log4j Issue

Workarounds

• In Log4j 2.10 or later, set the system property log4j2.formatMsgNoLookups=true to disable message lookup substitution
• Set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true as an alternative to the system property
• Modify the logging configuration to use %m{nolookups} pattern instead of %m in PatternLayout configurations
• Implement network-level filtering to block requests containing recursive lookup patterns before they reach vulnerable applications

# Configuration example
# Set JVM system property to disable lookups
java -Dlog4j2.formatMsgNoLookups=true -jar your-application.jar

# Or set environment variable
export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

# Remove JndiLookup class from existing jar (mitigation for older versions)
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class