官方消息
Fixed in Log4j 2.12.2 (Java 7) and Log4j 2.16.0 (Java 8)
Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations
| CVE-2021-45046 | Remote Code Execution |
|---|---|
| Severity | Critical |
| Base CVSS Score | 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) |
| Versions Affected | All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 |
https://logging.apache.org/log4j/2.x/security.html
CVE-2021-45046
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to localhost by default. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default.
https://logging.apache.org/log4j/2.x/security.html
History
Severity is now Critical
The original severity of this CVE was rated as Moderate; since this CVE was published security experts found additional exploits against the Log4j 2.15.0 release, that could lead to information leaks, RCE (remote code execution) and LCE (local code execution) attacks.
Base CVSS Score changed from 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) to 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).
The title of this CVE was changed from mentioning Denial of Service attacks to mentioning Remote Code Execution attacks.
Only Pattern Layouts with a Context Lookup (for example, $${ctx:loginId}) are vulnerable to this. This page previously incorrectly mentioned that Thread Context Map pattern (%X, %mdc, or %MDC) in the layout would also allow this vulnerability.
While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to localhost by default, there are ways to bypass this and users should not rely on this.
Older (discredited) mitigation measures
This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open.
Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.
The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.
Release Details
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. JNDI lookups in configuration now need to be enabled explicitly. Users are advised not to enable JNDI in Log4j 2.16.0. If the JMS Appender is required, use Log4j 2.12.2.
From version 2.12.2 (for Java 7), the message lookups feature has been completely removed. Lookups in configuration still work. Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in configuration now need to be enabled explicitly. When enabled, JNDI will only support the java protocol.
Work in progress
The Log4j team will continue to actively update this page as more information becomes known.
Credit
This issue was discovered by Kai Mindermann of iC Consult and separately by 4ra1n.
Additional vulnerability details discovered independently by Ash Fox of Google, Anthony Weems of Praetorian, and RyotaK
简单来说，就是请继续升级……
