https://logging.apache.org/log4j/2.x/ 最近一個周的時間 log4j2 從 2.14 躍升到了2.17 還在不停的升級 安全問題正是焦頭爛額 free software 和 opensource 的實質 其實是 自有 而不是 免費. 大家都把free 理解成了免費, 導致現在所有的開源軟件 大家都缺少動力. 很多時候 愛好也重要. 但是喫飯更重要.
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.
Important: Security Vulnerability CVE-2021-45105
The Log4j team has been made aware of a security vulnerability, CVE-2021-45105, that has been addressed in Log4j 2.17.0 for Java 8 and up.
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
From version 2.17.0 (for Java 8), only lookup strings in configuration are expanded recursively; in any other usage, only the top-level lookup is resolved, and any nested lookups are not resolved.
In prior releases this issue can be mitigated by ensuring your logging configuration does the following:
- In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId}or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
- Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.
Reference
Please refer to the Security page for details and mitigation measures for older versions of Log4j.
Important: Security Vulnerability CVE-2021-45046
The Log4j team has been made aware of a security vulnerability, CVE-2021-45046, that has been addressed in Log4j 2.12.2 for Java 7 and 2.16.0 for Java 8 and up.
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.
Note that previous mitigations involving configuration such as setting the system property log4j2.formatMsgNoLookups to true do NOT mitigate this specific vulnerability.
Mitigation
In version 2.12.2 (for Java 7), Log4j disables access to JNDI by default. Usage of JNDI in configuration now needs to be enabled explicitly. Calls to the JndiLookup will now return a constant string. Also, Log4j now limits the protocols by default to only java. The message lookups feature has been completely removed. Lookups in configuration still work.
From version 2.16.0 (for Java 8), the message lookups feature has been completely removed. Lookups in configuration still work. Furthermore, Log4j now disables access to JNDI by default. Users are advised not to enable JNDI in Log4j 2.16.0. If the JMS Appender is required, use Log4j 2.12.2.
Reference
Please refer to the Security page for details and mitigation measures for older versions of Log4j.
Important: Security Vulnerability CVE-2021-44228
The Log4j team has been made aware of a security vulnerability, CVE-2021-44228, that has been addressed in Log4j 2.12.2 and Log4j 2.16.0.
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
In version 2.12.2 (for Java 7), Log4j disables access to JNDI by default. Usage of JNDI in configuration now needs to be enabled explicitly. Calls to the JndiLookup will now return a constant string. Also, Log4j now limits the protocols by default to only java. The message lookups feature has been completely removed. Lookups in configuration still work.
From version 2.16.0 (for Java 8), the message lookups feature has been completely removed. Lookups in configuration still work. Furthermore, Log4j now disables access to JNDI by default. Users are advised not to enable JNDI in Log4j 2.16.0. If the JMS Appender is required, use Log4j 2.12.2.
Reference
Please refer to the Security page for mitigation measures for older versions of Log4j.
Features
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.
The Log4j API is a logging facade that may, of course, be used with the Log4j implementation, but may also be used in front of other logging implementations such as Logback. The Log4j API has several advantages over SLF4J: 1. The Log4j API supports logging Messages instead of just Strings. 2. The Log4j API supports lambda expressions. 3. The Log4j API provides many more logging methods than SLF4J. 4. In addition to the “parameterized logging” format supported by SLF4J, the Log4j API also supports events using the java.text.MessageFormat syntax as well printf-style messages. 5. The Log4j API provides a LogManager.shutdown() method. The underlying logging implementation must implement the Terminable interface for the method to have effect. 6. Other constructs such as Markers, log Levels, and ThreadContext (aka MDC) are fully supported.
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 significantly outperforms Log4j 1.x, Logback and java.util.logging, especially in multi-threaded applications. 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 Log4j 1.2, SLF4J, Commons Logging and java.util.logging (JUL) APIs.
Avoid lock-in
Applications coded to the Log4j 2 API always have the option to use any SLF4J-compliant library as their logger implementation with the log4j-to-slf4j adapter.
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.
Java 8 Lambda Support
Previously, if a log message was expensive to construct, you would often explicitly check if the requested log level is enabled before constructing the message. Client code running on Java 8 can benefit from Log4j’s lambda support. Since Log4j will not evaluate a lambda expression if the requested log level is not enabled, the same effect can be achieved with less code.
Custom Log Levels
In Log4j 2, custom log levels can easily be defined in code or in configuration. No subclassing is required.
Log Builder API
In addition to using one of the many log methods in the Log4j API, log events can be constructed using a builder. See [Log Builder][manual/logbuilder.html] for more information.
Garbage-free
During steady state logging, Log4j 2 is garbage-free in stand-alone applications, and low garbage in web applications. This reduces pressure on the garbage collector and can give better response time performance.
Integrating with Application Servers
Version 2.10.0 added the module log4j-appserver to improve integration with Apache Tomcat and Eclipse Jetty.
Cloud Enabled
Version 2.12.0 introduced support for accessing Docker container information via a Lookup and for accessing and updating the Log4j configuration through Spring Cloud Configuration. This support was enhanced in version 2.13.0 to add support for accessing Spring Boot properties as well as Kubernetes information. See Logging in the Cloud for details.
Compatible with Log4j 1.x
The Log4j-1.2-api module of Log4j 2 provides compatiblity for applications using the Log4j 1 logging methods. As of Log4j 2.13.0 Log4j 2 also provides experimental support for Log4j 1.x configuration files. See Log4j 2 Compatiblity with Log4j 1 for more information.
Documentation
The Log4j 2 User’s Guide is available on this site or as a downloadable PDF.
Requirements
Log4j 2.13.0 and greater require Java 8. Version 2.4 through 2.12.1 required Java 7 (the Log4j team no longer supports Java 7). Some features require optional dependencies; the documentation for these features will specify the required dependencies.
News
Log4j 2.17.0 has been released solely to:
- Address CVE-2021-45105.
- Require components that use JNDI to be enabled individually via system properties.
- Remove LDAP and LDAPS as supported protocols from JNDI.
2.17.0 is a recommended upgrade to ensure that recursive lookups do not cause services to fail.
Log4j 2.17.0 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, SLF4J, and java.util.logging.
Log4j 2.17.0 is the latest release of Log4j. As of Log4j 2.13.0 Log4j 2 requires Java 8 or greater at runtime. This release contains new features and fixes which can be found in the latest changes report.
Log4j 2.17.0 maintains binary compatibility with previous releases.