[logging-log4j-site] branch asf-staging updated: Clarify CVE-2021-44228 text on top page

[rp...@apache.org]

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 <re...@yahoo.com>
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&#x2019;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&#x2019;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&#x2019;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&#x2019;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&#x2019;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 &gt;=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>