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 615e767 Update for CVE-2021-45046
615e767 is described below
commit 615e7671b58286b956306c8a1318e8d91ac7e2ab
Author: Remko Popma <rem...@yahoo.com>
AuthorDate: Wed Dec 15 03:06:52 2021 +0900
Update for CVE-2021-45046
---
log4j-2.16.0/index.html | 30 ++++++++++++++++++++++++------
log4j-2.16.0/security.html | 42 ++++++++++++++++++++++++++++++++++++++----
2 files changed, 62 insertions(+), 10 deletions(-)
diff --git a/log4j-2.16.0/index.html b/log4j-2.16.0/index.html
index e9b4834..d028440 100644
--- a/log4j-2.16.0/index.html
+++ b/log4j-2.16.0/index.html
@@ -158,12 +158,30 @@
-->
<h1>Apache Log4j 2</h1>
<p>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.</p><section>
-<h2><a name="Important:_Security_Vulnerability_CVE-2021-44228"></a><a
name="CVE-2021-44228"></a>Important: Security Vulnerability CVE-2021-44228</h2>
-<p>The Log4j team has been made aware of a security vulnerability,
CVE-2021-44228, that has been addressed in Log4j 2.16.0.</p>
-<p>Log4j’s JNDI support has not restricted what names could be
resolved. Some protocols are unsafe or can allow remote code execution.</p>
-<p>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) att [...]
-<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>
-<p>Please refer to the <a href="security.html#CVE-2021-44228">Security
page</a> for mitigation measures for older versions of
Log4j.</p></section><section>
+
+<p><a name="CVE-2021-45046"></a></p><section>
+<h2><a name="Important:_Security_Vulnerability_CVE-2021-45046"></a>Important:
Security Vulnerability CVE-2021-45046</h2>
+<p>The Log4j team has been made aware of a security vulnerability,
CVE-2021-45046, that has been addressed in Log4j 2.16.0.</p>
+<p>Summary: Apache Log4j2 Thread Context Message Pattern and Context Lookup
Pattern vulnerable to a denial of service attack.</p><section><section>
+<h4><a name="Details"></a>Details</h4>
+<p>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 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. [...]
+<p>Note that previous mitigations involving configuration such as setting the
system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific
vulnerability.</p></section><section>
+<h4><a name="Mitigation"></a>Mitigation</h4>
+<p>From version 2.16.0, Log4j 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. The message lookups feature has been
completely removed.</p></section><section>
+<h4><a name="Reference"></a>Reference</h4>
+<p>Please refer to the <a href="security.html#CVE-2021-45046">Security
page</a> for details and mitigation measures for older versions of Log4j.</p>
+<p><a name="CVE-2021-44228"></a></p></section></section></section><section>
+<h2><a name="Important:_Security_Vulnerability_CVE-2021-44228"></a>Important:
Security Vulnerability CVE-2021-44228</h2>
+<p>The Log4j team has been made aware of a security vulnerability,
CVE-2021-44228, that has been addressed in Log4j 2.16.0.</p><section><section>
+<h4><a name="Summary"></a>Summary</h4>
+<p>Log4j’s JNDI support has not restricted what names could be
resolved. Some protocols are unsafe or can allow remote code
execution.</p></section><section>
+<h4><a name="Details"></a>Details</h4>
+<p>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) att [...]
+<h4><a name="Mitigation"></a>Mitigation</h4>
+<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>
+<h4><a name="Reference"></a>Reference</h4>
+<p>Please refer to the <a href="security.html#CVE-2021-44228">Security
page</a> for mitigation measures for older versions of
Log4j.</p></section></section></section><section>
+
<h2><a name="Features"></a>Features</h2><section>
<h3><a name="API_Separation"></a>API Separation</h3>
<p>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.</p>
diff --git a/log4j-2.16.0/security.html b/log4j-2.16.0/security.html
index ae92f77..173af17 100644
--- a/log4j-2.16.0/security.html
+++ b/log4j-2.16.0/security.html
@@ -163,8 +163,42 @@
<p>Please note that binary patches are never provided. If you need to apply a
source code patch, use the building instructions for the Apache Log4j version
that you are using. For Log4j 2 this is BUILDING.md. This file can be found in
the root subdirectory of a source distributive.</p>
<p>If you need help on building or configuring Log4j or other help on
following the instructions to mitigate the known vulnerabilities listed here,
please send your questions to the public Log4j Users mailing list</p>
<p>If you have encountered an unlisted security vulnerability or other
unexpected behaviour that has security impact, or if the descriptions here are
incomplete, please report them privately to the <a class="externalLink"
href="mailto:priv...@logging.apache.org";>Log4j Security Team</a>. Thank
you.</p><section><section>
-<p><a name="CVE-2021-44228"></a> <a
name="cve-2021-44228"></a></p><section><section>
-<h3><a name="Fixed_in_Log4j_2.15.0_and_2.16.0"></a>Fixed in Log4j
2.16.0</h3><section>
+
+<p><a name="CVE-2021-45046"></a> <a
name="cve-2021-45046"></a></p><section><section>
+<h3><a name="Fixed_in_Log4j_2.16.0"></a>Fixed in Log4j 2.16.0</h3><section>
+<h4><a name="CVE-2021-45046"></a>CVE-2021-45046</h4>
+<p><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a>:
Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern
vulnerable to a denial of service attack.</p>
+<p>Severity: Moderate</p>
+<p>Base CVSS Score: 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)</p>
+<p>Versions Affected: all versions from 2.0-beta9 to
2.15.0</p></section><section>
+<h4><a name="Description"></a>Description</h4>
+<p>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) atta [...]
+<h4><a name="Mitigation"></a>Mitigation</h4>
+<p><b>Log4j 1.x mitigation</b>: Log4j 1.x is not impacted by this
vulnerability.</p>
+<p><b>Log4j 2.x mitigation</b>: Implement one of the mitigation techniques
below.</p>
+<ul>
+
+ <li>Java 8 (or later) users should upgrade to release 2.16.0.</li>
+ <li>Users requiring Java 7 should upgrade to release 2.12.2 when it
becomes available (work in progress, expected to be available soon).</li>
+ <li>Otherwise, remove the JndiLookup class from the classpath: zip -q -d
log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class</li>
+</ul>
+<p>Note that only the log4j-core JAR file is impacted by this vulnerability.
Applications using only the log4j-api JAR file without the log4j-core JAR file
are not impacted by this vulnerability.</p></section><section>
+<h4><a name="History"></a>History</h4>
+<p><b>Older (discredited) mitigation measures</b></p>
+<p>This page previously mentioned other mitigation measures, but we discovered
that these measures only limit exposure while leaving some attack vectors
open.</p>
+<p>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.</p>
+<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>
+<p><b>Release Details</b></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>
+<h4><a name="Work_in_progress"></a>Work in progress</h4>
+<p>The Log4j team will continue to actively update this page as more
information becomes known.</p></section><section>
+<h4><a name="Credit"></a>Credit</h4>
+<p>This issue was discovered by Kai Mindermann of iC
Consult.</p></section><section>
+<h4><a name="References"></a>References</h4>
+<p><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3221";>https://issues.apache.org/jira/browse/LOG4J2-3221</a></p>
+<p><a name="CVE-2021-44228"></a> <a
name="cve-2021-44228"></a></p></section></section><section>
+<h3><a name="Fixed_in_Log4j_2.15.0"></a>Fixed in Log4j 2.15.0</h3><section>
<h4><a name="CVE-2021-44228"></a>CVE-2021-44228</h4>
<p><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>:
Apache Log4j2 JNDI features do not protect against attacker controlled LDAP
and other JNDI related endpoints.</p>
<p>Severity: Critical</p>
@@ -186,6 +220,7 @@
<p><b>Older (discredited) mitigation measures</b></p>
<p>This page previously mentioned other mitigation measures, but we discovered
that these measures only limit exposure while leaving some attack vectors
open.</p>
<p>The 2.15.0 release was found to still be vulnerable when the configuration
has a pattern layout containing a Context Lookup (for example,
$${ctx:loginId}), or a Thread Context Map pattern %X, %mdc or %MDC. When an
attacker can control Thread Context values, they may inject a JNDI Lookup
pattern, which will be evaluated and result in a JNDI connection. Log4j 2.15.0
restricts JNDI connections to localhost by default, but this may still result
in DOS (Denial of Service) attacks, or worse.</p>
+<p>A new CVE (CVE-2021-45046, see above) was raised for this.</p>
<p>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.</p>
<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>
@@ -195,8 +230,7 @@
<h4><a name="Work_in_progress"></a>Work in progress</h4>
<p>The Log4j team will continue to actively update this page as more
information becomes known.</p></section><section>
<h4><a name="Credit"></a>Credit</h4>
-<p>This issue was discovered by Chen Zhaojun of Alibaba Cloud Security
Team.</p>
-<p>The ThreadContext attack vector was first discovered by Kai Mindermann of
iC Consult.</p></section><section>
+<p>This issue was discovered by Chen Zhaojun of Alibaba Cloud Security
Team.</p></section><section>
<h4><a name="References"></a>References</h4>
<p><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3201";>https://issues.apache.org/jira/browse/LOG4J2-3201</a>
and <a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3198";>https://issues.apache.org/jira/browse/LOG4J2-3198</a>.</p></section></section><section>
