You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@logging.apache.org by rp...@apache.org on 2021/12/14 09:54:38 UTC

[logging-log4j-site] branch asf-staging updated: Fix broken anchor link to CVE-2021-44228 section in securities page

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 5834c06  Fix broken anchor link to CVE-2021-44228 section in securities page
5834c06 is described below

commit 5834c0691433f05bf03047dd2be5acc5022923bc
Author: Remko Popma <re...@yahoo.com>
AuthorDate: Tue Dec 14 18:54:28 2021 +0900

    Fix broken anchor link to CVE-2021-44228 section in securities page
---
 log4j-2.16.0/index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/log4j-2.16.0/index.html b/log4j-2.16.0/index.html
index 0cb6555..e41857a 100644
--- a/log4j-2.16.0/index.html
+++ b/log4j-2.16.0/index.html
@@ -164,7 +164,7 @@
 <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>
+<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>
 <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>