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 5f259e5 Clarify CVE-2021-44228 text on top page
new 8c7a5a6 Merge remote-tracking branch 'origin/asf-staging' into
asf-staging
5f259e5 is described below
commit 5f259e559240250f069b402e5405ec979c13b1a2
Author: Remko Popma <[email protected]>
AuthorDate: Tue Dec 14 16:17:44 2021 +0900
Clarify CVE-2021-44228 text on top page
---
log4j-2.16.0/index.html | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/log4j-2.16.0/index.html b/log4j-2.16.0/index.html
index de32149..0cb6555 100644
--- a/log4j-2.16.0/index.html
+++ b/log4j-2.16.0/index.html
@@ -158,6 +158,13 @@
-->
<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.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-4422">Security page</a>
for mitigation measures for older versions of Log4j.</p></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>
@@ -196,11 +203,6 @@
<p>Log4j 2.13.0 and greater require Java 8. Version 2.4 through 2.12.1
required Java 7 (the Log4j team no longer supports Java 7). Some features
require optional dependencies; the documentation for these features will
specify the required dependencies.</p></section><section>
<h2><a name="News"></a>News</h2>
<p>Log4j 2.16.0 has been released solely to disable access to JNDI by default
and completely remove the ability to use Lookups in messages. The CVE noted
below was fixed in the 2.15.0 release. 2.16.0 is a recommended upgrade to
ensure that JNDI will not be abused and that message Lookups are no longer
possible.</p><section>
-<h3><a name="CVE-2021-44228"></a>CVE-2021-44228</h3>
-<p>The Log4j team has been made aware of a security vulnerability,
CVE-2021-44228, that has been addressed in Log4j 2.15.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. Log4j
now limits the protocols by default to only java, ldap, and ldaps and limits
the ldap protocols to only accessing Java primitive objects by default served
on the local host.</p>
-<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>For those who cannot upgrade to 2.15.0, in releases >=2.10, this
vulnerability can be mitigated by setting either the system property
log4j2.formatMsgNoLookups or the environment variable
LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases from 2.7 through 2.14.1 all
PatternLayout patterns can be modified to specify the message converter as
%m{nnolookups} instead of just %m. For releases from 2.0-beta9 to 2.10.0, the
mitigation is to remove the JndiLookup class from the classpath:zip [...]
<h3><a name="Other_News"></a>Other News</h3>
<p>Log4j 2.16.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.16.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.16.0">changes report</a>.</p>
