Source: apache-log4j2 Version: 2.15.0-1 Severity: grave Tags: security upstream Justification: user security hole Forwarded: https://issues.apache.org/jira/browse/LOG4J2-3221 X-Debbugs-Cc: car...@debian.org, Debian Security Team <t...@security.debian.org> Control: found -1 2.15.0-1~deb11u1 Control: found -1 2.15.0-1~deb10u1
Hi, The following vulnerability was published for apache-log4j2. Strictly speaking it's less severe as CVE-2021-44228 as it is an incomplete fix for the former CVE in certain non-default configurations. CVE-2021-45046[0]: | 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 restricts JNDI LDAP lookups to | localhost by default. Note that previous mitigations involving | configuration such as to set the system property | `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific | vulnerability. Log4j 2.16.0 fixes this issue by removing support for | message lookup patterns and disabling JNDI functionality by default. | This issue can be mitigated in prior releases (<2.16.0) by removing | the JndiLookup class from the classpath (example: zip -q -d | log4j-core-*.jar | org/apache/logging/log4j/core/lookup/JndiLookup.class). If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-45046 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 [1] https://issues.apache.org/jira/browse/LOG4J2-3221 [2] https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046 [3] https://www.openwall.com/lists/oss-security/2021/12/14/4 Regards, Salvatore