You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@logging.apache.org by rp...@apache.org on 2021/12/17 05:19:15 UTC
[logging-log4j-site] branch asf-staging updated: CVE-2021-45046 severity critical (additional minor fixes 4)
This is an automated email from the ASF dual-hosted git repository.
rpopma pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/logging-log4j-site.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new a07f886 CVE-2021-45046 severity critical (additional minor fixes 4)
a07f886 is described below
commit a07f8866e4ee71750d85311a0e2e4b4defe236a7
Author: Remko Popma <re...@yahoo.com>
AuthorDate: Fri Dec 17 14:19:08 2021 +0900
CVE-2021-45046 severity critical (additional minor fixes 4)
---
log4j-2.16.0/security.html | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/log4j-2.16.0/security.html b/log4j-2.16.0/security.html
index f0bb0a5..79932eb 100644
--- a/log4j-2.16.0/security.html
+++ b/log4j-2.16.0/security.html
@@ -207,7 +207,7 @@
<p><b>Severity is now Critical</b></p>
<p>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.</p>
<p>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).</p>
- <p>The title of this CVE was changed from mentioning Denial of Service attacks to remote code execution attacks.</p>
+ <p>The title of this CVE was changed from mentioning Denial of Service attacks to mentioning Remote Code Execution attacks.</p>
<p>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.</p>
<p>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.</p>
<p><b>Older (discredited) mitigation measures</b></p>
@@ -216,7 +216,8 @@
<p>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.</p>
<p>The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.</p></section><section>
<h3><a name="Release_Details"></a>Release Details</h3>
- <p>From version 2.16.0, 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. Also, Log4j now limits the protocols by default to only java, ldap, and ldaps and limits the ldap protocols to only accessing Java primitive objects. Hosts other than the local host need to be explicitly allowed.</p></section><section>
+ <p>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.</p>
+ <p>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. Hosts other than the local host need to be explicitly allowed.</p></section><section>
<h3><a name="Work_in_progress"></a>Work in progress</h3>
<p>The Log4j team will continue to actively update this page as more information becomes known.</p></section><section>
<h3><a name="Credit"></a>Credit</h3>
@@ -274,8 +275,9 @@
<p>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.</p>
<p>The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.</p></section><section>
<h4><a name="Release_Details"></a>Release Details</h4>
- <p>As of Log4j 2.15.0 the message lookups feature was disabled by default. Lookups in configuration still work. While Log4j 2.15.0 has an option to enable Lookups in this fashion, users are strongly discouraged from enabling it. A whitelisting mechanism was introduced for JNDI connections, allowing only localhost by default.</p>
- <p>From version 2.16.0, 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. Also, Log4j now limits the protocols by default to only java, ldap, and ldaps and limits the ldap protocols to only accessing Java primitive objects. Hosts other than the local host need to be explicitly allowed.</p></section></section><section>
+ <p>As of Log4j 2.15.0 the message lookups feature was disabled by default. Lookups in configuration still work. While Log4j 2.15.0 has an option to enable Lookups in this fashion, users are strongly discouraged from enabling it. A whitelisting mechanism was introduced for JNDI connections, allowing only localhost by default. The 2.15.0 release was found to have additional vulnerabilities and is not recommended.</p>
+ <p>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.</p>
+ <p>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. Hosts other than the local host need to be explicitly allowed.</p></section></section><section>
<h3><a name="Work_in_progress"></a>Work in progress</h3>
<p>The Log4j team will continue to actively update this page as more information becomes known.</p></section><section>
<h3><a name="Credit"></a>Credit</h3>