You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@logging.apache.org by vy...@apache.org on 2021/12/10 21:39:03 UTC
[logging-log4j-site] branch asf-staging updated (00a366e -> f36f679)
This is an automated email from the ASF dual-hosted git repository.
vy pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/logging-log4j-site.git.
discard 00a366e Update mitigation techniques for CVE-2021-44228.
new f36f679 Update mitigation techniques for CVE-2021-44228.
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (00a366e)
\
N -- N -- N refs/heads/asf-staging (f36f679)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
log4j-2.15.0/index.html | 2 +-
log4j-2.15.0/security.html | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
[logging-log4j-site] 01/01: Update mitigation techniques for CVE-2021-44228.
Posted by vy...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
vy pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/logging-log4j-site.git
commit f36f679d81cc3c8e25beae092e9619f885ee2a87
Author: Volkan Yazıcı <vo...@yazi.ci>
AuthorDate: Fri Dec 10 21:57:28 2021 +0100
Update mitigation techniques for CVE-2021-44228.
---
log4j-2.15.0/index.html | 8 +-------
log4j-2.15.0/security.html | 2 +-
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/log4j-2.15.0/index.html b/log4j-2.15.0/index.html
index a0f3f22..e8c7f62 100644
--- a/log4j-2.15.0/index.html
+++ b/log4j-2.15.0/index.html
@@ -202,14 +202,8 @@
<p>One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages. As of Log4j 2.15.0 this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it.</p>
-<p>Users who cannot upgrade to 2.15.0 can mitigate the exposure by:
-<ul>
-<li>>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.</li>
-<li>>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.</li>
-<li>>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.</li>
-</ul>
+<p>For those who cannot upgrade to 2.15.0, in releases >=2.10, this vulnerability can be mitigated by setting either the system property <code>log4j2.formatMsgNoLookups</code> or the environment variable <code>LOG4J_FORMAT_MSG_NO_LOOKUPS</code> to <code>true</code>. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the <code>JndiLookup</code> class from the classpath: <code>zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class</code>.</p>
-</p>
<h3>Other News</h3>
<p>Log4j 2.15.0 is now available for production. The API for Log4j 2 is not compatible with Log4j 1.x, however an adapter is available to allow applications to continue to use the Log4j 1.x API. Adapters are also available for Apache Commons Logging, SLF4J, and java.util.logging.</p>
<p>Log4j 2.15.0 is the latest release of Log4j. As of Log4j 2.13.0 Log4j 2 requires Java 8 or greater at runtime. This release contains new features and fixes which can be found in the latest <a href="changes-report.html#a2.15.0">changes report</a>.</p>
diff --git a/log4j-2.15.0/security.html b/log4j-2.15.0/security.html
index 056123b..5135f10 100644
--- a/log4j-2.15.0/security.html
+++ b/log4j-2.15.0/security.html
@@ -169,7 +169,7 @@
<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>
<p>Descripton: 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.</p>
-<p>Mitigation: In previous releases (>=2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true” 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 RCE by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trust [...]
+<p>Mitigation: In releases >=2.10, this behavior can be mitigated by setting either the system property <code>log4j2.formatMsgNoLookups</code> or the environment variable <code>LOG4J_FORMAT_MSG_NO_LOOKUPS</code> to <code>true</code>. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the <code>JndiLookup</code> class from the classpath: <code>zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class</code>.
<p>Credit: This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.</p>
<p>References: <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>