Source: apache-log4j2 Version: 2.13.3-1 Severity: grave Tags: security upstream Justification: user security hole Forwarded: https://issues.apache.org/jira/browse/LOG4J2-3198 https://github.com/apache/logging-log4j2/pull/608 X-Debbugs-Cc: car...@debian.org, Debian Security Team <t...@security.debian.org> Control: found -1 2.11.1-2 Control: found -1 2.7-2
Hi, The following vulnerability was published for apache-log4j2. I'm still choosing grave for the severity, though there are some mitigating factors depending on the Java version used. See for details the references, in particular [3]. Additionally according to latest comments in [4] the issue seems not to be completely fixed. As the lookup is performed after formatting the message, which includes the user input, the vulnerability could still be triggered using a ParametrizedMessage. See [4] the comments from Eric Everman and Volkan Yazici. CVE-2021-44228[0]: | Apache Log4j2 <=2.14.1 JNDI features used in configuration, log | messages, and parameters do not protect against attacker controlled | LDAP and other JNDI related endpoints. An attacker who can control log | messages or log message parameters can execute arbitrary code loaded | from LDAP servers when message lookup substitution is enabled. From | log4j 2.15.0, this behavior has been disabled by default. In previous | releases (>2.10) this behavior can be mitigated by setting system | property "log4j2.formatMsgNoLookups" to &#8220;true&#8221; or | by removing the JndiLookup class from the classpath (example: zip -q | -d log4j-core-*.jar | org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 | (see | https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) | protects against remote code execution by defaulting | "com.sun.jndi.rmi.object.trustURLCodebase" and | "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false". 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-44228 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 [1] https://github.com/advisories/GHSA-jfh8-c2jp-5v3q [2] https://github.com/apache/logging-log4j2/pull/608 [3] https://www.lunasec.io/docs/blog/log4j-zero-day/ [4] https://issues.apache.org/jira/browse/LOG4J2-3198 Regards, Salvatore