This is an automated email from the ASF dual-hosted git repository.
rgoers 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 733b27e Update for 2.12.2
733b27e is described below
commit 733b27e89d57ba8f7cbd7afa9e8722c660904f35
Author: Ralph Goers <[email protected]>
AuthorDate: Tue Dec 14 13:47:07 2021 -0700
Update for 2.12.2
---
log4j-2.16.0/index.html | 10 ++++++----
log4j-2.16.0/security.html | 11 ++++++-----
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/log4j-2.16.0/index.html b/log4j-2.16.0/index.html
index 7c7159b..cd69186 100644
--- a/log4j-2.16.0/index.html
+++ b/log4j-2.16.0/index.html
@@ -161,24 +161,26 @@
<p><a name="CVE-2021-45046"></a></p><section>
<h2><a name="Important:_Security_Vulnerability_CVE-2021-45046"></a>Important:
Security Vulnerability CVE-2021-45046</h2>
-<p>The Log4j team has been made aware of a security vulnerability,
CVE-2021-45046, that has been addressed in Log4j 2.16.0.</p>
+<p>The Log4j team has been made aware of a security vulnerability,
CVE-2021-45046, that has been addressed in Log4j 2.12.2 for Java 7 and 2.16.0
for Java 8 and up.</p>
<p>Summary: Apache Log4j2 Thread Context Message Pattern and Context Lookup
Pattern vulnerable to a denial of service attack.</p><section><section>
<h4><a name="Details"></a>Details</h4>
<p>It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0
was incomplete in certain non-default configurations. This could allows
attackers with control over Thread Context Map (MDC) input data when the
logging configuration uses a Pattern Layout with either a Context Lookup (for
example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC)
to craft malicious input data using a JNDI Lookup pattern resulting in a denial
of service (DOS) attack. Log4j 2. [...]
<p>Note that previous mitigations involving configuration such as setting the
system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific
vulnerability.</p></section><section>
<h4><a name="Mitigation"></a>Mitigation</h4>
-<p>From version 2.16.0, Log4j 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. The message lookups feature has been
completely removed.</p></section><section>
+<p>In version 2.12.2 Log4j disables access to JNDI by default. Usage of JNDI
in configuration now need to be enabled explicitly. Calls to the JndiLookup
will now return a constant string. Also, Log4j now limits the protocols by
default to only java. The message lookups feature has been completely
removed.</p></section><section>
+<p>In version 2.16.0 Log4j 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. The ldap and ldaps protocols will be
removed in the next release. The message lookups feature has been completely
removed.</p></section><section>
<h4><a name="Reference"></a>Reference</h4>
<p>Please refer to the <a href="security.html#CVE-2021-45046">Security
page</a> for details and mitigation measures for older versions of Log4j.</p>
<p><a name="CVE-2021-44228"></a></p></section></section></section><section>
<h2><a name="Important:_Security_Vulnerability_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.16.0.</p><section><section>
+<p>The Log4j team has been made aware of a security vulnerability,
CVE-2021-44228, that has been addressed in Log4j 2.12.2 and Log4j
2.16.0.</p><section><section>
<h4><a name="Summary"></a>Summary</h4>
<p>Log4j’s JNDI support has not restricted what names could be
resolved. Some protocols are unsafe or can allow remote code
execution.</p></section><section>
<h4><a name="Details"></a>Details</h4>
<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 [...]
<h4><a name="Mitigation"></a>Mitigation</h4>
-<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></section><section>
+<p>In version 2.12.2 Log4j disables access to JNDI by default. Usage of JNDI
in configuration now need to be enabled explicitly. Calls to the JndiLookup
will now return a constant string. Also, Log4j now limits the protocols by
default to only java. The message lookups feature has been completely removed.
+<p>In 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></section><section>
<h4><a name="Reference"></a>Reference</h4>
<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></section><section>
diff --git a/log4j-2.16.0/security.html b/log4j-2.16.0/security.html
index a301d8c..3b119ec 100644
--- a/log4j-2.16.0/security.html
+++ b/log4j-2.16.0/security.html
@@ -165,12 +165,12 @@
<p>If you have encountered an unlisted security vulnerability or other
unexpected behaviour that has security impact, or if the descriptions here are
incomplete, please report them privately to the <a class="externalLink"
href="mailto:[email protected]";>Log4j Security Team</a>. Thank
you.</p><section><section>
<p><a name="CVE-2021-45046"></a> <a
name="cve-2021-45046"></a></p><section><section>
-<h3><a name="Fixed_in_Log4j_2.16.0"></a>Fixed in Log4j 2.16.0</h3><section>
+<h3><a name="Fixed_in_Log4j_2.16.0"></a>Fixed in Log4j 2.12.2 and Log4j
2.16.0</h3><section>
<h4><a name="CVE-2021-45046"></a>CVE-2021-45046</h4>
<p><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a>:
Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern
vulnerable to a denial of service attack.</p>
<p>Severity: Moderate</p>
<p>Base CVSS Score: 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)</p>
-<p>Versions Affected: all versions from 2.0-beta9 to
2.15.0</p></section><section>
+<p>Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0
through 2.15.0</p></section><section>
<h4><a name="Description"></a>Description</h4>
<p>It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0
was incomplete in certain non-default configurations. This could allows
attackers with control over Thread Context Map (MDC) input data when the
logging configuration uses a non-default Pattern Layout with either a Context
Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X,
%mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern
resulting in a denial of service (DOS) atta [...]
<h4><a name="Mitigation"></a>Mitigation</h4>
@@ -190,7 +190,8 @@
<p>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.</p>
<p>The safest thing to do is to upgrade Log4j to a safe version, or remove the
JndiLookup class from the log4j-core jar.</p>
<p><b>Release Details</b></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></section><section>
+<p>In version 2.12.2 the message lookups feature has been completely removed.
Lookups in configuration still work. Furthermore, Log4j now disables access to
JNDI by default. JNDI lookups will now return a constant value. Also, Log4j now
limits the protocols by default to only java.</p></section><section>
+<p>In 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></section><section>
<h4><a name="Work_in_progress"></a>Work in progress</h4>
<p>The Log4j team will continue to actively update this page as more
information becomes known.</p></section><section>
<h4><a name="Credit"></a>Credit</h4>
@@ -203,9 +204,9 @@
<p><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>:
Apache Log4j2 JNDI features do not protect against attacker controlled LDAP
and other JNDI related endpoints.</p>
<p>Severity: Critical</p>
<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></section><section>
+<p>Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0
through 2.14.1</p></section><section>
<h4><a name="Description"></a>Description</h4>
-<p>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.</p></section><section>
+<p>In Apache Log4j2 versions up to and including 2.14.1 (excluding security
release 2.12.2), 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.</p></section><section>
<h4><a name="Mitigation"></a>Mitigation</h4>
<p><b>Log4j 1.x mitigation</b>: Log4j 1.x does not have Lookups so the risk is
lower. Applications using Log4j 1.x are only vulnerable to this attack when
they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been
filed for this vulnerability. To mitigate: audit your logging configuration to
ensure it has no JMSAppender configured. Log4j 1.x configurations without
JMSAppender are not impacted by this vulnerability.</p>
<p><b>Log4j 2.x mitigation</b>: Implement one of the mitigation techniques
below.</p>
