Apache logging services logo Apache log4j logo

Important: Security Vulnerabilities CVE-2021-45105, CVE-2021-45046 and CVE-2021-44228

CVE-2021-45105

Summary: Apache Log4j2 does not always protect from infinite recursion in lookup evaluation.

Details

Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.

Mitigation

Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

Reference

Please refer to the Security page for details and mitigation measures for older versions of Log4j.

CVE-2021-45046

Summary: Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations.

Details

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on macOS but no other tested environments.

Mitigation

Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

Reference

Please refer to the Security page for details and mitigation measures for older versions of Log4j.

CVE-2021-44228

Summary: Log4j’s JNDI support has not restricted what names could be resolved. Some protocols are unsafe or can allow remote code execution.

Details

One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages. This meant that when user input is logged, and that user input contained a JNDI Lookup pointing to a malicious server, then Log4j would resolve that JNDI Lookup, connect to that server, and potentially download serialized Java code from that remote server. This in turn could execute any code during deserialization. This is known as a RCE (Remote Code Execution) attack.

Mitigation

Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

Reference

Please refer to the Security page for details and mitigation measures for older versions of Log4j.

Apache Log4j 2

Apache Log4j 2 is an upgrade to Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides many of the improvements available in Logback while fixing some inherent problems in Logback's architecture.

Some of the features and improvements in Log4j 2 are:

API Separation
The API for Log4j is separate from the implementation making it clear for application developers which classes and methods they can use while ensuring forward compatibility. This allows the Log4j team to improve the implementation safely and in a compatible manner.
Improved Performance
Log4j 2 contains next-generation Asynchronous Loggers based on the LMAX Disruptor library. In multi-threaded scenarios Asynchronous Loggers have 18 times higher throughput and orders of magnitude lower latency than Log4j 1.x and Logback. See Asynchronous Logging Performance for details. Otherwise, Log4j 2 performs faster than Log4j 1.x in critical areas and similarly to Logback under most circumstances. See Performance for more information.
Support for multiple APIs
While the Log4j 2 API will provide the best performance, Log4j 2 provides support for the SLF4J and Commons Logging APIs.
Automatic Reloading of Configurations
Like Logback, Log4j 2 can automatically reload its configuration upon modification. Unlike Logback, it will do so without losing log events while reconfiguration is taking place.
Advanced Filtering
Like Logback, Log4j 2 supports filtering based on context data, markers, regular expressions, and other components in the Log event. Filtering can be specified to apply to all events before being passed to Loggers or as they pass through Appenders. In addition, filters can also be associated with Loggers. Unlike Logback, you can use a common Filter class in any of these circumstances.
Plugin Architecture
Log4j uses the plugin pattern to configure components. As such, you do not need to write code to create and configure an Appender, Layout, Pattern Converter, and so on. Log4j automatically recognizes plugins and uses them when a configuration references them.
Property Support
You can reference properties in a configuration, Log4j will directly replace them, or Log4j will pass them to an underlying component that will dynamically resolve them. Properties come from values defined in the configuration file, system properties, environment variables, the ThreadContext Map, and data present in the event. Users can further customize the property providers by adding their own Lookup Plugin.

Documentation

The Log4j 2 User's Guide is available on this site or as a downloadable PDF.

Requirements

Log4j 2 requires Java 6. Some features require optional dependencies; the documentation for these features specifies the dependencies.

News

Log4j 2 is now available for production. The API for Log4j 2 is not compatible with Log4j 1.x, however an adapter is available to allow applications to continue to use the Log4j 1.x API. Adapters are also available for Apache Commons Logging and SLF4J.