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 be4700e [DOC] Temporarily remove references to 2.12.2, recommend 2.16
only, move 2.15 to discredited solutions
be4700e is described below
commit be4700ed61ef2e53a21551465edb9766af4f1a9a
Author: Remko Popma <rem...@yahoo.com>
AuthorDate: Tue Dec 14 23:04:08 2021 +0900
[DOC] Temporarily remove references to 2.12.2, recommend 2.16 only, move
2.15 to discredited solutions
---
log4j-2.16.0/index.html | 1 -
log4j-2.16.0/security.html | 21 +++++++++++----------
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/log4j-2.16.0/index.html b/log4j-2.16.0/index.html
index e41857a..2a7953d 100644
--- a/log4j-2.16.0/index.html
+++ b/log4j-2.16.0/index.html
@@ -162,7 +162,6 @@
<p>The Log4j team has been made aware of a security vulnerability,
CVE-2021-44228, that has been addressed in Log4j 2.15.0 and 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>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.</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>
<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>
<h2><a name="Features"></a>Features</h2><section>
diff --git a/log4j-2.16.0/security.html b/log4j-2.16.0/security.html
index 9e3fc59..a6110fa 100644
--- a/log4j-2.16.0/security.html
+++ b/log4j-2.16.0/security.html
@@ -171,32 +171,33 @@
<p>Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H</p>
<p>Versions Affected: all versions from 2.0-beta9 to
2.14.1</p></section><section>
<h4><a name="Description"></a>Description</h4>
-<p>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.</p></section><section>
+<p>In Apache Log4j2 versions up to and including 2.14.1, the JNDI features
used in configurations, 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.</p></section><section>
<h4><a name="Mitigation"></a>Mitigation</h4>
<p><b>Log4j 1.x mitigation</b>: Log4j 1.x does not have Lookups so the risk is
lower. Applications using Log4j 1.x are only vulnerable to this attack when
they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been
filed for this vulnerability. To mitigate: audit your logging configuration to
ensure it has no JMSAppender configured. Log4j 1.x configurations without
JMSAppender are not impacted by this vulnerability.</p>
<p><b>Log4j 2.x mitigation</b>: Implement one of the mitigation techniques
below.</p>
<ul>
- <li>Upgrade to release 2.15.0 or later (2.16.0 is recommended) - requires
Java 8 or later.</li>
- <li>Users requiring Java 7, upgrade to release 2.12.2.</li>
+ <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>We strongly recommend upgrading Log4j to a safe version, or removing the
JndiLookup class from the log4j-core jar.</p>
-<p>This page previously had other mitigation measures, but we discovered that
these measures only limit exposure while leaving some attack vectors open.</p>
-<p>These 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 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 removing the
JndiLookup class from the log4j-core class.</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>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>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.</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>
-<p>A version 2.12.2 has been released for users who cannot upgrade to 2.16.0
because they require Java 7. This release is based on Log4j 2.12.1, with the
same security changes as 2.16.0: it removes the message lookups feature
completely, disables JNDI by default, and only allows access to Java primitive
objects. It is actually even stricter than 2.16.0, in that it allows only the
java protocol (ldap and ldaps protocols will not work).</p></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.</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="Credit"></a>Credit</h4>
<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>
+
<h3><a name="Fixed_in_Log4j_2.13.2"></a>Fixed in Log4j 2.13.2</h3>
<p><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a>:
Improper validation of certificate with host mismatch in Apache Log4j SMTP
appender.</p>
<p>Severity: Low</p>
