This is an automated email from the ASF dual-hosted git repository.
rpopma pushed a commit to branch release-2.x
in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
The following commit(s) were added to refs/heads/release-2.x by this push:
new 69023fa [DOC] Temporarily remove references to 2.12.2, recommend 2.16
only, move 2.15 to discredited solutions
69023fa is described below
commit 69023fa43619ed3c1f6d7a665d301c76b4af0bd1
Author: rpopma <rpo...@apache.org>
AuthorDate: Tue Dec 14 23:03:30 2021 +0900
[DOC] Temporarily remove references to 2.12.2, recommend 2.16 only, move
2.15 to discredited solutions
---
src/site/markdown/index.md.vm | 9 ---------
src/site/markdown/security.md | 32 +++++++++++++++++---------------
2 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/src/site/markdown/index.md.vm b/src/site/markdown/index.md.vm
index e3de3e6..947d0ae 100644
--- a/src/site/markdown/index.md.vm
+++ b/src/site/markdown/index.md.vm
@@ -44,20 +44,11 @@ that remote server. This in turn could execute any code
during deserialization.
This is known as a RCE (Remote Code Execution) attack.
$h4 Mitigation
-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.
-
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.
-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).
-
$h4 Reference
Please refer to the [Security page](security.html#CVE-2021-44228) for
mitigation measures for older versions of Log4j.
diff --git a/src/site/markdown/security.md b/src/site/markdown/security.md
index 86c2272..9697daa 100644
--- a/src/site/markdown/security.md
+++ b/src/site/markdown/security.md
@@ -60,8 +60,9 @@ Base CVSS Score: 10.0
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Versions Affected: all versions from 2.0-beta9 to 2.14.1
#### Description
-In Apache Log4j2 2.14.1, the JNDI features used in configurations, log
messages, and parameters do not
-protect against an attacker-controlled LDAP and other JNDI related endpoints.
An attacker who can control log
+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.
@@ -74,8 +75,8 @@ Log4j 1.x configurations without JMSAppender are not impacted
by this vulnerabil
**Log4j 2.x mitigation**: Implement one of the mitigation techniques below.
-* Java 8 (or later) users should upgrade to release 2.15.0 or later, 2.16.0 is
recommended.
-* Java 7 users should upgrade to release 2.12.2.
+* Java 8 (or later) users should upgrade to release 2.16.0.
+* Users requiring Java 7 should upgrade to release 2.12.2 when it becomes
available (work in progress, expected to be available soon).
* Otherwise, remove the JndiLookup class from the classpath: `zip -q -d
log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class`
Note that only the log4j-core JAR file is impacted by this vulnerability.
@@ -84,33 +85,34 @@ Applications using only the log4j-api JAR file without the
log4j-core JAR file a
#### History
**Older (discredited) mitigation measures**
-We strongly recommend upgrading Log4j to a safe version, or removing the
JndiLookup class from the log4j-core jar.
+This page previously mentioned other mitigation measures, but we discovered
that these measures only limit exposure while leaving some attack vectors open.
-This page previously had other mitigation measures, but we discovered that
these measures only limit exposure while leaving some attack vectors open.
+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.
-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.
+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.
-The reason these measures are insufficient is that there are still code paths
in Log4j where message lookups could occur:
+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.
-The safest thing to do is to upgrade Log4j to a safe version, or removing the
JndiLookup class from the log4j-core class.
+
+The safest thing to do is to upgrade Log4j to a safe version, or remove the
JndiLookup class from the log4j-core jar.
**Release Details**
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.
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.
-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).
-
#### Credit
This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
