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 550ac0a Update 2.17.0 About page and Security page for releases 2.3.1
and 2.12.3
550ac0a is described below
commit 550ac0ad501b857267c129fc934412c013599b84
Author: Remko Popma <rem...@yahoo.com>
AuthorDate: Wed Dec 22 11:43:41 2021 +0900
Update 2.17.0 About page and Security page for releases 2.3.1 and 2.12.3
---
log4j-2.17.0/index.html | 72 +++----
log4j-2.17.0/security.html | 528 +++++++++++++++++++++++----------------------
2 files changed, 299 insertions(+), 301 deletions(-)
diff --git a/log4j-2.17.0/index.html b/log4j-2.17.0/index.html
index 3ea2298..85e1446 100644
--- a/log4j-2.17.0/index.html
+++ b/log4j-2.17.0/index.html
@@ -157,47 +157,39 @@
limitations under the License.
-->
<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>
-<p><a name="CVE-2021-45105"></a></p><section>
-<h2><a name="Important:_Security_Vulnerability_CVE-2021-45105"></a>Important:
Security Vulnerability CVE-2021-45105</h2>
-<p>The Log4j team has been made aware of a security vulnerability,
CVE-2021-45105, that has been addressed in Log4j 2.17.0 for Java 8 and up.</p>
-<p>Summary: Apache Log4j2 does not always protect from infinite recursion in
lookup evaluation.</p><section><section>
-<h4><a name="Details"></a>Details</h4>
-<p>Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from
uncontrolled recursion from self-referential lookups. When the logging
configuration uses a non-default Pattern Layout with a Context Lookup (for
example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC)
input data can craft malicious input data that contains a recursive lookup,
resulting in a StackOverflowError that will terminate the process. This is also
known as a DOS (Denial of Service) at [...]
-<h4><a name="Mitigation"></a>Mitigation</h4>
-<p>From version 2.17.0 (for Java 8), only lookup strings in configuration are
expanded recursively; in any other usage, only the top-level lookup is
resolved, and any nested lookups are not resolved.</p>
-<p>In prior releases this issue can be mitigated by ensuring your logging
configuration does the following:</p>
-<ul>
+<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_Vulnerabilities_CVE-2021-45105.2C_CVE-2021-45046_and_CVE-2021-44228"></a>Important:
Security Vulnerabilities CVE-2021-45105, CVE-2021-45046 and CVE-2021-44228</h2>
+ <p><a name="CVE-2021-45105"></a></p><section>
+ <h3><a name="CVE-2021-45105"></a>CVE-2021-45105</h3>
+ <p>Summary: Apache Log4j2 does not always protect from infinite
recursion in lookup evaluation.</p><section>
+ <h4><a name="Details"></a>Details</h4>
+ <p>Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not
protect from uncontrolled recursion from self-referential lookups. When the
logging configuration uses a non-default Pattern Layout with a Context Lookup
(for example, $${ctx:loginId}), attackers with control over Thread Context Map
(MDC) input data can craft malicious input data that contains a recursive
lookup, resulting in a StackOverflowError that will terminate the process. This
is also known as a DOS (Denial of [...]
+ <h4><a name="Mitigation"></a>Mitigation</h4>
+ <p>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or
2.17.0 (for Java 8 and later).</p></section><section>
+ <h4><a name="Reference"></a>Reference</h4>
+ <p>Please refer to the <a class="externalLink"
href="https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105";>Security
page</a> for details and mitigation measures for older versions of Log4j.</p>
+ <p><a name="CVE-2021-45046"></a></p></section></section><section>
+ <h3><a name="CVE-2021-45046"></a>CVE-2021-45046</h3>
+ <p>Summary: Apache Log4j2 Thread Context Lookup Pattern vulnerable
to remote code execution in certain non-default configurations.</p><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. When the
logging configuration uses a non-default Pattern Layout with a Context Lookup
(for example, $${ctx:loginId}), attackers with control over Thread Context Map
(MDC) input data can craft malicious input data using a JNDI Lookup pattern,
resulting in an information leak and remote code execution in some environments
and local code execution [...]
+ <h4><a name="Mitigation"></a>Mitigation</h4>
+ <p>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or
2.17.0 (for Java 8 and later).</p></section><section>
+ <h4><a name="Reference"></a>Reference</h4>
+ <p>Please refer to the <a class="externalLink"
href="https://logging.apache.org/log4j/2.x/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>
+ <h3><a name="CVE-2021-44228"></a>CVE-2021-44228</h3>
+ <p>Summary: Log4j’s JNDI support has not restricted what
names could be resolved. Some protocols are unsafe or can allow remote code
execution.</p><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 Ex [...]
+ <h4><a name="Mitigation"></a>Mitigation</h4>
+ <p>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or
2.17.0 (for Java 8 and later).</p></section><section>
+ <h4><a name="Reference"></a>Reference</h4>
+ <p>Please refer to the <a class="externalLink"
href="https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228";>Security
page</a> for details and mitigation measures for older versions of
Log4j.</p></section></section></section><section>
+
-<li>In PatternLayout in the logging configuration, replace Context Lookups
like ${ctx:loginId}or $${ctx:loginId} with Thread Context Map patterns (%X,
%mdc, or %MDC).</li>
-<li>Otherwise, in the configuration, remove references to Context Lookups like
${ctx:loginId} or $${ctx:loginId} where they originate from sources external to
the application such as HTTP headers or user input.</li>
-</ul></section><section>
-<h4><a name="Reference"></a>Reference</h4>
-<p>Please refer to the <a href="security.html#CVE-2021-45105">Security
page</a> for details and mitigation measures for older versions of Log4j.</p>
-<p><a name="CVE-2021-45046"></a></p></section></section></section><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.12.2 for Java 7 and 2.16.0
for Java 8 and up.</p>
-<p>Summary: Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote
code execution in certain non-default configurations.</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. When the logging
configuration uses a non-default Pattern Layout with a Context Lookup (for
example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC)
input data can craft malicious input data using a JNDI Lookup pattern,
resulting in an information leak and remote code execution in some environments
and local code execution in all envir [...]
-<p>Note that previous mitigations involving configuration such as setting the
system property log4j2.formatMsgNoLookups to true do NOT mitigate this specific
vulnerability.</p></section><section>
-<h4><a name="Mitigation"></a>Mitigation</h4>
-<p>In version 2.12.2 (for Java 7), Log4j disables access to JNDI by default.
Usage of JNDI in configuration now needs 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. Lookups in configuration still work.</p>
-<p>From version 2.16.0 (for Java 8), the message lookups feature has been
completely removed. Lookups in configuration still work. Furthermore, Log4j now
disables access to JNDI by default. Users are advised not to enable JNDI in
Log4j 2.16.0. If the JMS Appender is required, use Log4j
2.12.2.</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.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>In version 2.12.2 (for Java 7), Log4j disables access to JNDI by default.
Usage of JNDI in configuration now needs 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. Lookups in configuration still work.</p>
-<p>From version 2.16.0 (for Java 8), the message lookups feature has been
completely removed. Lookups in configuration still work. Furthermore, Log4j now
disables access to JNDI by default. Users are advised not to enable JNDI in
Log4j 2.16.0. If the JMS Appender is required, use Log4j
2.12.2.</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>
<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>
diff --git a/log4j-2.17.0/security.html b/log4j-2.17.0/security.html
index 3de8d8b..6ea9fd0 100644
--- a/log4j-2.17.0/security.html
+++ b/log4j-2.17.0/security.html
@@ -138,288 +138,294 @@
</div>
</div>
</header>
- <main id="bodyColumn" class="span10" >
-<!-- vim: set syn=markdown : -->
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0
+ <main id="bodyColumn" class="span10" >
+ <!-- vim: set syn=markdown : -->
+ <!--
+ Licensed to the Apache Software Foundation (ASF) under one or
more
+ contributor license agreements. See the NOTICE file distributed
with
+ this work for additional information regarding copyright
ownership.
+ The ASF licenses this file to You under the Apache License,
Version 2.0
+ (the "License"); you may not use this file except in compliance
with
+ the License. You may obtain a copy of the License at
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-<h1>Apache Log4j Security Vulnerabilities</h1>
-<p>This page lists all the security vulnerabilities fixed in released versions
of Apache Log4j 2. Each vulnerability is given a <a
href="#Security_Impact_Levels">security impact rating</a> by the <a
class="externalLink" href="mailto:priv...@logging.apache.org";>Apache Logging
security team</a>. please note that this rating may vary from platform to
platform. We also list the versions of Apache Log4j the flaw is known to
affect, and where a flaw has not been verified list the version with [...]
-<p>Note: Vulnerabilities that are not Log4j vulnerabilities but have either
been incorrectly reported against Log4j or where Log4j provides a workaround
are listed at the end of this page.</p>
-<p>Please note that Log4j 1.x has reached end of life and is no longer
supported. Vulnerabilities reported after August 2015 against Log4j 1.x were
not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain
security fixes.</p>
-<p>Please note that binary patches are never provided. If you need to apply a
source code patch, use the building instructions for the Apache Log4j version
that you are using. For Log4j 2 this is BUILDING.md. This file can be found in
the root subdirectory of a source distributive.</p>
-<p>If you need help on building or configuring Log4j or other help on
following the instructions to mitigate the known vulnerabilities listed here,
please send your questions to the public Log4j Users mailing list</p>
-<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:priv...@logging.apache.org";>Log4j Security Team</a>. Thank you.</p>
-<p><a name="CVE-2021-45105"></a><a name="cve-2021-45046"></a></p><section>
-<h2><a name="Fixed_in_Log4j_2.17.0_.28Java_8.29"></a><a
name="log4j-2.17.0"></a> Fixed in Log4j 2.17.0 (Java 8)</h2>
-<p><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a>:<br
/>
-Apache Log4j2 does not always protect from infinite recursion in lookup
evaluation</p>
-<table border="0" class="table table-striped">
-<thead>
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
software
+ distributed under the License is distributed on an "AS IS"
BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ See the License for the specific language governing permissions
and
+ limitations under the License.
+ -->
+ <h1>Apache Log4j Security Vulnerabilities</h1>
+ <p>This page lists all the security vulnerabilities fixed in
released versions of Apache Log4j 2. Each vulnerability is given a <a
href="#Security_Impact_Levels">security impact rating</a> by the <a
class="externalLink" href="mailto:priv...@logging.apache.org";>Apache Logging
security team</a>. please note that this rating may vary from platform to
platform. We also list the versions of Apache Log4j the flaw is known to
affect, and where a flaw has not been verified list the [...]
+ <p>Note: Vulnerabilities that are not Log4j vulnerabilities but
have either been incorrectly reported against Log4j or where Log4j provides a
workaround are listed at the end of this page.</p>
+ <p>Please note that Log4j 1.x has reached end of life and is no
longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x
were not checked and will not be fixed. Users should upgrade to Log4j 2 to
obtain security fixes.</p>
+ <p>Please note that binary patches are never provided. If you
need to apply a source code patch, use the building instructions for the Apache
Log4j version that you are using. For Log4j 2 this is BUILDING.md. This file
can be found in the root subdirectory of a source distributive.</p>
+ <p>If you need help on building or configuring Log4j or other
help on following the instructions to mitigate the known vulnerabilities listed
here, please send your questions to the public Log4j Users mailing list</p>
+ <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:priv...@logging.apache.org";>Log4j Security
Team</a>. Thank you.</p>
+ <p><a name="CVE-2021-45105"></a><a
name="cve-2021-45046"></a></p><section>
+ <h2><a
name="Fixed_in_Log4j_2.17.0_.28Java_8.29.2C_2.12.3_.28Java_7.29_and_2.3.1_.28Java_6.29"></a><a
name="log4j-2.17.0"></a> Fixed in Log4j 2.17.0 (Java 8), 2.12.3 (Java 7) and
2.3.1 (Java 6)</h2>
+ <p><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a>:<br
/>
+ Apache Log4j2 does not always protect from infinite
recursion in lookup evaluation</p>
+ <table border="0" class="table table-striped">
+ <thead>
+
+ <tr class="a">
+ <th> <a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a>
</th>
+ <th> Denial of Service </th></tr>
+ </thead><tbody>
+
+ <tr class="b">
+ <td> Severity </td>
+ <td> High </td></tr>
+ <tr class="a">
+ <td> Base CVSS Score </td>
+ <td> 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) </td></tr>
+ <tr class="b">
+ <td> Versions Affected </td>
+ <td> All versions from 2.0-beta9 to 2.16.0, excluding 2.12.3
</td></tr>
+ </tbody>
+ </table><section>
+ <h3><a name="Description"></a>Description</h3>
+ <p>Apache Log4j2 versions 2.0-alpha1 through 2.16.0, excluding
2.12.3, did not protect from uncontrolled recursion from self-referential
lookups. When the logging configuration uses a non-default Pattern Layout with
a Context Lookup (for example, $${ctx:loginId}), attackers with control over
Thread Context Map (MDC) input data can craft malicious input data that
contains a recursive lookup, resulting in a StackOverflowError that will
terminate the process. This is also know [...]
+ <h3><a name="Mitigation"></a>Mitigation</h3><section>
+ <h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
+ <p>Log4j 1.x is not impacted by this
vulnerability.</p></section><section>
+ <h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
+ <p>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or
2.17.0 (for Java 8 and later).</p>
+ <p>Alternatively, this infinite recursion issue can be mitigated
in configuration:</p>
+ <ul>
-<tr class="a">
-<th> <a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a>
</th>
-<th> Denial of Service </th></tr>
-</thead><tbody>
+ <li>In PatternLayout in the logging configuration, replace
Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map
patterns (%X, %mdc, or %MDC).</li>
+ <li>Otherwise, in the configuration, remove references to
Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate
from sources external to the application such as HTTP headers or user
input.</li>
+ </ul>
+ <p>Note that only the log4j-core JAR file is impacted by this
vulnerability. Applications using only the log4j-api JAR file without the
log4j-core JAR file are not impacted by this vulnerability.</p>
+ <p>Also note that Apache Log4j is the only Logging Services
subproject affected by this vulnerability. Other projects like Log4net and
Log4cxx are not impacted by this.</p></section></section><section>
+ <h3><a name="Release_Details"></a>Release Details</h3>
+ <p>From version 2.17.0, (and 2.12.3 and 2.3.1 for Java 7 and
Java 6), only lookup strings in configuration are expanded recursively; in any
other usage, only the top-level lookup is resolved, and any nested lookups are
not resolved.</p>
+ <p>The property to enable JNDI has been renamed from
‘log4j2.enableJndi’ to three separate properties:
‘log4j2.enableJndiLookup’, ‘log4j2.enableJndiJms’,
and ‘log4j2.enableJndiContextSelector’.</p>
+ <p>JNDI functionality has been hardened in these versions:
2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, support for the
LDAP protocol has been removed and only the JAVA protocol is supported in JNDI
connections.</p></section><section>
+ <h3><a name="Work_in_progress"></a>Work in progress</h3>
+ <p>The Log4j team will continue to actively update this page as
more information becomes known.</p></section><section>
+ <h3><a name="Credit"></a>Credit</h3>
+ <p>Independently discovered by Hideki Okamoto of Akamai
Technologies, Guy Lederfein of Trend Micro Research working with Trend
Micro’s Zero Day Initiative, and another anonymous vulnerability
researcher.</p></section><section>
+ <h3><a name="References"></a>References</h3>
+ <ul>
-<tr class="b">
-<td> Severity </td>
-<td> High </td></tr>
-<tr class="a">
-<td> Base CVSS Score </td>
-<td> 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-beta9 to 2.16.0 </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<p>Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from
uncontrolled recursion from self-referential lookups. When the logging
configuration uses a non-default Pattern Layout with a Context Lookup (for
example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC)
input data can craft malicious input data that contains a recursive lookup,
resulting in a StackOverflowError that will terminate the process. This is also
known as a DOS (Denial of Service) at [...]
-<h3><a name="Mitigation"></a>Mitigation</h3><section>
-<h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
-<p>Log4j 1.x is not impacted by this vulnerability.</p></section><section>
-<h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
-<p>Implement one of the following mitigation techniques:</p>
-<ul>
+ <li><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a></li>
+ <li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3230";>LOG4J2-3230</a></li>
+ </ul>
+ <p><a name="CVE-2021-45046"></a><a
name="cve-2021-45046"></a></p></section></section><section>
+ <h2><a
name="Fixed_in_Log4j_2.16.0_.28Java_8.29_and_Log4j_2.12.2_.28Java_7.29"></a><a
name="log4j-2.16.0"></a> Fixed in Log4j 2.16.0 (Java 8) and Log4j 2.12.2 (Java
7)</h2>
+ <p><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a>:<br
/>
+ Apache Log4j2 Thread Context Lookup Pattern vulnerable to
remote code execution in certain non-default configurations</p>
+ <table border="0" class="table table-striped">
+ <thead>
-<li>Java 8 (or later) users should upgrade to release 2.17.0.</li>
-</ul>
-<p>Alternatively, this can be mitigated in configuration:</p>
-<ul>
+ <tr class="a">
+ <th> <a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a>
</th>
+ <th> Remote Code Execution </th></tr>
+ </thead><tbody>
-<li>In PatternLayout in the logging configuration, replace Context Lookups
like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X,
%mdc, or %MDC).</li>
-<li>Otherwise, in the configuration, remove references to Context Lookups like
${ctx:loginId} or $${ctx:loginId} where they originate from sources external to
the application such as HTTP headers or user input.</li>
-</ul>
-<p>Note that only the log4j-core JAR file is impacted by this vulnerability.
Applications using only the log4j-api JAR file without the log4j-core JAR file
are not impacted by this vulnerability.</p>
-<p>Also note that Apache Log4j is the only Logging Services subproject
affected by this vulnerability. Other projects like Log4net and Log4cxx are not
impacted by this.</p></section></section><section>
-<h3><a name="Work_in_progress"></a>Work in progress</h3>
-<p>The Log4j team will continue to actively update this page as more
information becomes known.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>Independently discovered by Hideki Okamoto of Akamai Technologies, Guy
Lederfein of Trend Micro Research working with Trend Micro’s Zero Day
Initiative, and another anonymous vulnerability
researcher.</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
+ <tr class="b">
+ <td> Severity </td>
+ <td> Critical </td></tr>
+ <tr class="a">
+ <td> Base CVSS Score </td>
+ <td> 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) </td></tr>
+ <tr class="b">
+ <td> Versions Affected </td>
+ <td> All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2
</td></tr>
+ </tbody>
+ </table><section>
+ <h3><a name="Description"></a>Description</h3>
+ <p>It was found that the fix to address <a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>
in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.
When the logging configuration uses a non-default Pattern Layout with a Context
Lookup (for example, $${ctx:loginId}), attackers with control over Thread
Context Map (MDC) input data can craft malicious input data using a JNDI Lookup
pattern, result [...]
+ <h3><a name="Mitigation"></a>Mitigation</h3><section>
+ <h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
+ <p>Log4j 1.x is not impacted by this
vulnerability.</p></section><section>
+ <h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
+ <p>Implement one of the following mitigation techniques:</p>
+ <ul>
-<li><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105";>CVE-2021-45105</a></li>
-<li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3230";>LOG4J2-3230</a></li>
-</ul>
-<p><a name="CVE-2021-45046"></a><a
name="cve-2021-45046"></a></p></section></section><section>
-<h2><a
name="Fixed_in_Log4j_2.12.2_.28Java_7.29_and_Log4j_2.16.0_.28Java_8.29"></a><a
name="log4j-2.16.0"></a> Fixed in Log4j 2.12.2 (Java 7) and Log4j 2.16.0 (Java
8)</h2>
-<p><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a>:<br
/>
-Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code
execution in certain non-default configurations</p>
-<table border="0" class="table table-striped">
-<thead>
+ <li>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java
7), or 2.17.0 (for Java 8 and later).</li>
+ <li>Otherwise, in any release other than 2.16.0, you may
remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class</li>
+ </ul>
+ <p>Users are advised not to enable JNDI in Log4j 2.16.0, since
it still allows LDAP connections. If the JMS Appender is required, use one of
these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards,
only the JAVA protocol is supported in JNDI connections.</p>
+ <p>Note that only the log4j-core JAR file is impacted by this
vulnerability. Applications using only the log4j-api JAR file without the
log4j-core JAR file are not impacted by this vulnerability.</p>
+ <p>Also note that Apache Log4j is the only Logging Services
subproject affected by this vulnerability. Other projects like Log4net and
Log4cxx are not impacted by this.</p></section></section><section>
+ <h3><a name="History"></a>History</h3>
+ <p><b>Severity is now Critical</b></p>
+ <p>The original severity of this CVE was rated as Moderate;
since this CVE was published security experts found additional exploits against
the Log4j 2.15.0 release, that could lead to information leaks, RCE (remote
code execution) and LCE (local code execution) attacks.</p>
+ <p>Base CVSS Score changed from 3.7
(AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) to 9.0
(AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).</p>
+ <p>The title of this CVE was changed from mentioning Denial of
Service attacks to mentioning Remote Code Execution attacks.</p>
+ <p>Only Pattern Layouts with a Context Lookup (for example,
$${ctx:loginId}) are vulnerable to this. This page previously incorrectly
mentioned that Thread Context Map pattern (%X, %mdc, or %MDC) in the layout
would also allow this vulnerability.</p>
+ <p>While Log4j 2.15.0 makes a best-effort attempt to restrict
JNDI LDAP lookups to localhost by default, there are ways to bypass this and
users should not rely on this.</p>
+ <p><b>Older (discredited) mitigation measures</b></p>
+ <p>This page previously mentioned other mitigation measures, but
we discovered that these measures only limit exposure while leaving some attack
vectors open.</p>
+ <p>Other insufficient mitigation measures are: setting system
property log4j2.formatMsgNoLookups or environment variable
LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the
logging configuration to disable message lookups with %m{nolookups},
%msg{nolookups} or %message{nolookups} for releases >= 2.7 and <=
2.14.1.</p>
+ <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></section><section>
+ <h3><a name="Release_Details"></a>Release Details</h3>
+ <p>From version 2.16.0 (for Java 8), 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. Users are advised not to enable JNDI in Log4j
2.16.0, since it still allows LDAP connections. If the JMS Appender is
required, use one of these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from
these versions onwards, only th [...]
+ <p>From version 2.12.2 (for Java 7) and 2.3.1 (for Java 6), 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. When enabled, JNDI
will only support the JAVA protocol, support for the LDAP protocol has been
removed.</p>
+ <p>From version 2.17.0 (for Java 8), support for the LDAP
protocol has been removed and only the JAVA protocol is supported in JNDI
connections.</p>
+ <p>From version 2.17.0 (for Java 8), 2.12.3 (for Java 7) and
2.3.1 (for Java 6), the property to enable JNDI has been renamed from
‘log4j2.enableJndi’ to three separate properties:
‘log4j2.enableJndiLookup’, ‘log4j2.enableJndiJms’,
and ‘log4j2.enableJndiContextSelector’.</p></section><section>
+ <h3><a name="Work_in_progress"></a>Work in progress</h3>
+ <p>The Log4j team will continue to actively update this page as
more information becomes known.</p></section><section>
+ <h3><a name="Credit"></a>Credit</h3>
+ <p>This issue was discovered by Kai Mindermann of iC Consult and
separately by 4ra1n.</p>
+ <p>Additional vulnerability details discovered independently by
Ash Fox of Google, Alvaro Muñoz and Tony Torralba from GitHub, Anthony
Weems of Praetorian, and RyotaK (@ryotkak).</p></section><section>
+ <h3><a name="References"></a>References</h3>
+ <ul>
-<tr class="a">
-<th> <a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a>
</th>
-<th> Remote Code Execution </th></tr>
-</thead><tbody>
+ <li><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a></li>
+ <li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3221";>LOG4J2-3221</a></li>
+ </ul>
+ <p><a name="CVE-2021-44228"></a><a
name="cve-2021-44228"></a></p></section></section><section>
+ <h2><a name="Fixed_in_Log4j_2.15.0_.28Java_8.29"></a><a
name="log4j-2.15.0"></a> Fixed in Log4j 2.15.0 (Java 8)</h2>
+ <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>
+ <table border="0" class="table table-striped">
+ <thead>
-<tr class="b">
-<td> Severity </td>
-<td> Critical </td></tr>
-<tr class="a">
-<td> Base CVSS Score </td>
-<td> 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<p>It was found that the fix to address <a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>
in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.
When the logging configuration uses a non-default Pattern Layout with a Context
Lookup (for example, $${ctx:loginId}), attackers with control over Thread
Context Map (MDC) input data can craft malicious input data using a JNDI Lookup
pattern, resulting in an info [...]
-<h3><a name="Mitigation"></a>Mitigation</h3><section>
-<h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
-<p>Log4j 1.x is not impacted by this vulnerability.</p></section><section>
-<h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
-<p>Implement one of the following mitigation techniques:</p>
-<ul>
+ <tr class="a">
+ <th><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>
</th>
+ <th> Remote Code Execution </th></tr>
+ </thead><tbody>
-<li>Java 8 (or later) users should upgrade to release 2.16.0.</li>
-<li>Java 7 users should upgrade to release 2.12.2.</li>
-<li>Otherwise, in any release other than 2.16.0, you may remove the JndiLookup
class from the classpath: zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class</li>
-</ul>
-<p>Users are advised not to enable JNDI in Log4j 2.16.0. If the JMS Appender
is required, use Log4j 2.12.2.</p>
-<p>Note that only the log4j-core JAR file is impacted by this vulnerability.
Applications using only the log4j-api JAR file without the log4j-core JAR file
are not impacted by this vulnerability.</p>
-<p>Also note that Apache Log4j is the only Logging Services subproject
affected by this vulnerability. Other projects like Log4net and Log4cxx are not
impacted by this.</p></section></section><section>
-<h3><a name="History"></a>History</h3>
-<p><b>Severity is now Critical</b></p>
-<p>The original severity of this CVE was rated as Moderate; since this CVE was
published security experts found additional exploits against the Log4j 2.15.0
release, that could lead to information leaks, RCE (remote code execution) and
LCE (local code execution) attacks.</p>
-<p>Base CVSS Score changed from 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) to
9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).</p>
-<p>The title of this CVE was changed from mentioning Denial of Service attacks
to mentioning Remote Code Execution attacks.</p>
-<p>Only Pattern Layouts with a Context Lookup (for example, $${ctx:loginId})
are vulnerable to this. This page previously incorrectly mentioned that Thread
Context Map pattern (%X, %mdc, or %MDC) in the layout would also allow this
vulnerability.</p>
-<p>While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP
lookups to localhost by default, there are ways to bypass this and users should
not rely on this.</p>
-<p><b>Older (discredited) mitigation measures</b></p>
-<p>This page previously mentioned other mitigation measures, but we discovered
that these measures only limit exposure while leaving some attack vectors
open.</p>
-<p>Other insufficient mitigation measures are: setting system property
log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS
to true for releases >= 2.10, or modifying the logging configuration to
disable message lookups with %m{nolookups}, %msg{nolookups} or
%message{nolookups} for releases >= 2.7 and <= 2.14.1.</p>
-<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></section><section>
-<h3><a name="Release_Details"></a>Release Details</h3>
-<p>From version 2.16.0 (for Java 8), 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. Users are advised not to enable JNDI in Log4j 2.16.0. If
the JMS Appender is required, use Log4j 2.12.2.</p>
-<p>From version 2.12.2 (for Java 7), 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. When enabled, JNDI will only support the java
protocol.</p></section><section>
-<h3><a name="Work_in_progress"></a>Work in progress</h3>
-<p>The Log4j team will continue to actively update this page as more
information becomes known.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>This issue was discovered by Kai Mindermann of iC Consult and separately by
4ra1n.</p>
-<p>Additional vulnerability details discovered independently by Ash Fox of
Google, Alvaro Muñoz and Tony Torralba from GitHub, Anthony Weems of
Praetorian, and RyotaK (@ryotkak).</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
+ <tr class="b">
+ <td> Severity </td>
+ <td> Critical </td></tr>
+ <tr class="a">
+ <td> Base CVSS Score </td>
+ <td> 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
</td></tr>
+ <tr class="b">
+ <td> Versions Affected </td>
+ <td> All versions from 2.0-beta9 to 2.14.1 </td></tr>
+ </tbody>
+ </table><section>
+ <h3><a name="Description"></a>Description</h3>
+ <p>In Apache Log4j2 versions up to and including 2.14.1
(excluding security releases 2.3.1, 2.12.2 and 2.12.3), 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>
+ <h3><a name="Mitigation"></a>Mitigation</h3><section>
+ <h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
+ <p>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></section><section>
+ <h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
+ <p>Implement one of the following mitigation techniques:</p>
+ <ul>
-<li><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046";>CVE-2021-45046</a></li>
-<li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3221";>LOG4J2-3221</a></li>
-</ul>
-<p><a name="CVE-2021-44228"></a><a
name="cve-2021-44228"></a></p></section></section><section>
-<h2><a name="Fixed_in_Log4j_2.15.0_.28Java_8.29"></a><a
name="log4j-2.15.0"></a> Fixed in Log4j 2.15.0 (Java 8)</h2>
-<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>
-<table border="0" class="table table-striped">
-<thead>
+ <li>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java
7), or 2.17.0 (for Java 8 and later).</li>
+ <li>Otherwise, in any release other than 2.16.0, you may
remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class</li>
+ </ul>
+ <p>Note that only the log4j-core JAR file is impacted by this
vulnerability. Applications using only the log4j-api JAR file without the
log4j-core JAR file are not impacted by this vulnerability.</p>
+ <p>Also note that Apache Log4j is the only Logging Services
subproject affected by this vulnerability. Other projects like Log4net and
Log4cxx are not impacted by this.</p></section></section><section>
+ <h3><a name="History"></a>History</h3><section>
+ <h4><a
name="Older_.28discredited.29_mitigation_measures"></a>Older (discredited)
mitigation measures</h4>
+ <p>This page previously mentioned other mitigation measures, but
we discovered that these measures only limit exposure while leaving some attack
vectors open.</p>
+ <p>The 2.15.0 release was found to still be vulnerable when the
configuration has a Pattern Layout containing a Context Lookup (for example,
$${ctx:loginId}). When an attacker can control Thread Context values, they may
inject a JNDI Lookup pattern, which will be evaluated and result in a JNDI
connection. While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI
connections to localhost by default, there are ways to bypass this and users
should not rely on this.</p>
+ <p>A new CVE (CVE-2021-45046, see above) was raised for this.</p>
+ <p>Other insufficient mitigation measures are: setting system
property log4j2.formatMsgNoLookups or environment variable
LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the
logging configuration to disable message lookups with %m{nolookups},
%msg{nolookups} or %message{nolookups} for releases >= 2.7 and <=
2.14.1.</p>
+ <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></section><section>
+ <h4><a name="Release_Details"></a>Release Details</h4>
+ <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. A whitelisting mechanism was introduced for JNDI connections,
allowing only localhost by default. The 2.15.0 release was found to have
additional vulnerabilities and is not recommended.</p>
+ <p>From version 2.16.0 (for Java 8), 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. Users are advised not to enable JNDI in Log4j
2.16.0, since it still allows LDAP connections. If the JMS Appender is
required, use one of these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from
these versions onwards, only th [...]
+ <p>From version 2.12.2 (for Java 7) and 2.3.1 (for Java 6), 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. When enabled, JNDI
will only support the JAVA protocol, support for the LDAP protocol has been
removed.</p>
+ <p>From version 2.17.0 (for Java 8), support for the LDAP
protocol has been removed and only the JAVA protocol is supported in JNDI
connections.</p>
+ <p>From version 2.17.0 (for Java 8), 2.12.3 (for Java 7) and
2.3.1 (for Java 6), the property to enable JNDI has been renamed from
‘log4j2.enableJndi’ to three separate properties:
‘log4j2.enableJndiLookup’, ‘log4j2.enableJndiJms’,
and
‘log4j2.enableJndiContextSelector’.</p></section></section><section>
+ <h3><a name="Work_in_progress"></a>Work in progress</h3>
+ <p>The Log4j team will continue to actively update this page as
more information becomes known.</p></section><section>
+ <h3><a name="Credit"></a>Credit</h3>
+ <p>This issue was discovered by Chen Zhaojun of Alibaba Cloud
Security Team.</p></section><section>
+ <h3><a name="References"></a>References</h3>
+ <ul>
-<tr class="a">
-<th><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228";>CVE-2021-44228</a>
</th>
-<th> Remote Code Execution </th></tr>
-</thead><tbody>
+ <li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3201";>https://issues.apache.org/jira/browse/LOG4J2-3201</a></li>
+ <li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3198";>https://issues.apache.org/jira/browse/LOG4J2-3198</a>.</li>
+ </ul></section></section><section>
+ <h2><a name="Fixed_in_Log4j_2.13.2_.28Java_8.29"></a><a
name="log4j-2.13.2"></a> Fixed in Log4j 2.13.2 (Java 8)</h2>
+ <p><a name="CVE-2020-9488"></a><a name="cve-2020-9488"></a> <a
class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a>:
Improper validation of certificate with host mismatch in Apache Log4j SMTP
appender.</p>
+ <table border="0" class="table table-striped">
+ <thead>
-<tr class="b">
-<td> Severity </td>
-<td> Critical </td></tr>
-<tr class="a">
-<td> Base CVSS Score </td>
-<td> 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-beta9 to 2.14.1 </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<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>
-<h3><a name="Mitigation"></a>Mitigation</h3><section>
-<h4><a name="Log4j_1.x_mitigation"></a>Log4j 1.x mitigation</h4>
-<p>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></section><section>
-<h4><a name="Log4j_2.x_mitigation"></a>Log4j 2.x mitigation</h4>
-<p>Implement one of the following mitigation techniques:</p>
-<ul>
+ <tr class="a">
+ <th> <a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a>
</th>
+ <th> </th></tr>
+ </thead><tbody>
-<li>Java 8 (or later) users should upgrade to release 2.16.0.</li>
-<li>Java 7 users should upgrade to release 2.12.2.</li>
-<li>Otherwise, in any release other than 2.16.0, you may remove the JndiLookup
class from the classpath: zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class</li>
-</ul>
-<p>Note that only the log4j-core JAR file is impacted by this vulnerability.
Applications using only the log4j-api JAR file without the log4j-core JAR file
are not impacted by this vulnerability.</p>
-<p>Also note that Apache Log4j is the only Logging Services subproject
affected by this vulnerability. Other projects like Log4net and Log4cxx are not
impacted by this.</p></section></section><section>
-<h3><a name="History"></a>History</h3><section>
-<h4><a name="Older_.28discredited.29_mitigation_measures"></a>Older
(discredited) mitigation measures</h4>
-<p>This page previously mentioned other mitigation measures, but we discovered
that these measures only limit exposure while leaving some attack vectors
open.</p>
-<p>The 2.15.0 release was found to still be vulnerable when the configuration
has a Pattern Layout containing a Context Lookup (for example,
$${ctx:loginId}). When an attacker can control Thread Context values, they may
inject a JNDI Lookup pattern, which will be evaluated and result in a JNDI
connection. While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI
connections to localhost by default, there are ways to bypass this and users
should not rely on this.</p>
-<p>A new CVE (CVE-2021-45046, see above) was raised for this.</p>
-<p>Other insufficient mitigation measures are: setting system property
log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS
to true for releases >= 2.10, or modifying the logging configuration to
disable message lookups with %m{nolookups}, %msg{nolookups} or
%message{nolookups} for releases >= 2.7 and <= 2.14.1.</p>
-<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></section><section>
-<h4><a name="Release_Details"></a>Release Details</h4>
-<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. A
whitelisting mechanism was introduced for JNDI connections, allowing only
localhost by default. The 2.15.0 release was found to have additional
vulnerabilities and is not recommended.</p>
-<p>From version 2.16.0 (for Java 8), 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. Users are advised not to enable JNDI in Log4j 2.16.0. If
the JMS Appender is required, use Log4j 2.12.2.</p>
-<p>From version 2.12.2 (for Java 7), 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. When enabled, JNDI will only support the java
protocol.</p></section></section><section>
-<h3><a name="Work_in_progress"></a>Work in progress</h3>
-<p>The Log4j team will continue to actively update this page as more
information becomes known.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>This issue was discovered by Chen Zhaojun of Alibaba Cloud Security
Team.</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
+ <tr class="b">
+ <td> Severity </td>
+ <td> Low </td></tr>
+ <tr class="a">
+ <td> CVSS Base Score </td>
+ <td> 3.7 (Low) CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
</td></tr>
+ <tr class="b">
+ <td> Versions Affected </td>
+ <td> All versions from 2.0-alpha1 to 2.13.1 </td></tr>
+ </tbody>
+ </table><section>
+ <h3><a name="Description"></a>Description</h3>
+ <p>Improper validation of certificate with host mismatch in
Log4j2 SMTP appender. This could allow an SMTPS connection to be intercepted by
a man-in-the-middle attack which could leak any log messages sent through that
appender.</p>
+ <p>The reported issue was caused by an error in
SslConfiguration. Any element using SslConfiguration in the Log4j Configuration
is also affected by this issue. This includes HttpAppender, SocketAppender, and
SyslogAppender. Usages of SslConfiguration that are configured via system
properties are not affected.</p></section><section>
+ <h3><a name="Mitigation"></a>Mitigation</h3>
+ <p>Users should upgrade to Apache Log4j 2.13.2 which fixed this
issue in <a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-2819";>https://issues.apache.org/jira/browse/LOG4J2-2819</a>
by making SSL settings configurable for SMTPS mail sessions. As a workaround
for previous releases, users can set the mail.smtp.ssl.checkserveridentity
system property to true to enable SMTPS hostname verification for all SMTPS
mail sessions.</p></section><section>
+ <h3><a name="Credit"></a>Credit</h3>
+ <p>This issues was discovered by Peter
Stöckli.</p></section><section>
+ <h3><a name="References"></a>References</h3>
+ <ul>
-<li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3201";>https://issues.apache.org/jira/browse/LOG4J2-3201</a></li>
-<li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-3198";>https://issues.apache.org/jira/browse/LOG4J2-3198</a>.</li>
-</ul></section></section><section>
-<h2><a name="Fixed_in_Log4j_2.13.2_.28Java_8.29"></a><a
name="log4j-2.13.2"></a> Fixed in Log4j 2.13.2 (Java 8)</h2>
-<p><a name="CVE-2020-9488"></a><a name="cve-2020-9488"></a> <a
class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a>:
Improper validation of certificate with host mismatch in Apache Log4j SMTP
appender.</p>
-<table border="0" class="table table-striped">
-<thead>
+ <li><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a></li>
+ <li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-2819";>LOG4J2-2819</a></li>
+ </ul></section></section><section>
+ <h2><a name="Fixed_in_Log4j_2.8.2_.28Java_7.29"></a><a
name="log4j-2.8.2"></a> Fixed in Log4j 2.8.2 (Java 7)</h2>
+ <p><a name="CVE-2017-5645"></a><a name="cve-2017-5645"></a> <a
class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a>:
Apache Log4j socket receiver deserialization vulnerability.</p>
+ <table border="0" class="table table-striped">
+ <thead>
-<tr class="a">
-<th> <a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a>
</th>
-<th> </th></tr>
-</thead><tbody>
+ <tr class="a">
+ <th> <a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a>
</th>
+ <th> </th></tr>
+ </thead><tbody>
-<tr class="b">
-<td> Severity </td>
-<td> Low </td></tr>
-<tr class="a">
-<td> CVSS Base Score </td>
-<td> 3.7 (Low) CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-alpha1 to 2.13.1 </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<p>Improper validation of certificate with host mismatch in Log4j2 SMTP
appender. This could allow an SMTPS connection to be intercepted by a
man-in-the-middle attack which could leak any log messages sent through that
appender.</p>
-<p>The reported issue was caused by an error in SslConfiguration. Any element
using SslConfiguration in the Log4j Configuration is also affected by this
issue. This includes HttpAppender, SocketAppender, and SyslogAppender. Usages
of SslConfiguration that are configured via system properties are not
affected.</p></section><section>
-<h3><a name="Mitigation"></a>Mitigation</h3>
-<p>Users should upgrade to Apache Log4j 2.13.2 which fixed this issue in <a
class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-2819";>https://issues.apache.org/jira/browse/LOG4J2-2819</a>
by making SSL settings configurable for SMTPS mail sessions. As a workaround
for previous releases, users can set the mail.smtp.ssl.checkserveridentity
system property to true to enable SMTPS hostname verification for all SMTPS
mail sessions.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>This issues was discovered by Peter Stöckli.</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
+ <tr class="b">
+ <td> Severity </td>
+ <td> Moderate </td></tr>
+ <tr class="a">
+ <td> CVSS Base Score </td>
+ <td> 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) </td></tr>
+ <tr class="b">
+ <td> Versions Affected </td>
+ <td> All versions from 2.0-alpha1 to 2.8.1 </td></tr>
+ </tbody>
+ </table><section>
+ <h3><a name="Description"></a>Description</h3>
+ <p>When using the TCP socket server or UDP socket server to
receive serialized log events from another application, a specially crafted
binary payload can be sent that, when deserialized, can execute arbitrary
code.</p></section><section>
+ <h3><a name="Mitigation"></a>Mitigation</h3>
+ <p>Java 7 and above users should migrate to version 2.8.2 or
avoid using the socket server classes. Java 6 users should avoid using the TCP
or UDP socket server classes, or they can manually backport the <a
class="externalLink"
href="https://github.com/apache/logging-log4j2/commit/5dcc192";>security fix
commit</a> from 2.8.2.</p></section><section>
+ <h3><a name="Credit"></a>Credit</h3>
+ <p>This issue was discovered by Marcio Almeida de Macedo of Red
Team at Telstra</p></section><section>
+ <h3><a name="References"></a>References</h3>
+ <ul>
-<li><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488";>CVE-2020-9488</a></li>
-<li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-2819";>LOG4J2-2819</a></li>
-</ul></section></section><section>
-<h2><a name="Fixed_in_Log4j_2.8.2_.28Java_7.29"></a><a name="log4j-2.8.2"></a>
Fixed in Log4j 2.8.2 (Java 7)</h2>
-<p><a name="CVE-2017-5645"></a><a name="cve-2017-5645"></a> <a
class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a>:
Apache Log4j socket receiver deserialization vulnerability.</p>
-<table border="0" class="table table-striped">
-<thead>
+ <li><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a></li>
+ <li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-1863";>LOG4J2-1863</a></li>
+ <li><a class="externalLink"
href="https://github.com/apache/logging-log4j2/commit/5dcc192";>Security fix
commit</a></li>
+ </ul></section></section><section>
+ <h2><a
name="Summary_of_security_impact_levels_for_Apache_Log4j"></a><a
name="Security_Impact_Levels"></a> Summary of security impact levels for Apache
Log4j</h2>
+ <p>The Apache Log4j Security Team rates the impact of each
security flaw that affects Log4j. We’ve chosen a rating scale quite
similar to those used by other major vendors in order to be consistent.
Basically the goal of the rating system is to answer the question “How
worried should I be about this vulnerability?”.</p>
+ <p>Note that the rating chosen for each flaw is the worst
possible case across all architectures. To determine the exact impact of a
particular vulnerability on your own systems you will still need to read the
security advisories to find out more about the flaw.</p>
+ <p>We use the following descriptions to decide on the impact
rating to give each vulnerability:</p><section>
+ <h3><a name="Critical"></a>Critical</h3>
+ <p>A vulnerability rated with a Critical impact is one which
could potentially be exploited by a remote attacker to get Log4j to execute
arbitrary code (either as the user the server is running as, or root). These
are the sorts of vulnerabilities that could be exploited automatically by
worms.</p></section><section>
+ <h3><a name="Important"></a>Important</h3>
+ <p>A vulnerability rated as Important impact is one which could
result in the compromise of data or availability of the server. For Log4j this
includes issues that allow an easy remote denial of service (something that is
out of proportion to the attack or with a lasting consequence), access to
arbitrary files outside of the context root, or access to files that should be
otherwise prevented by limits or authentication.</p></section><section>
+ <h3><a name="Moderate"></a>Moderate</h3>
+ <p>A vulnerability is likely to be rated as Moderate if there is
significant mitigation to make the issue less of an impact. This might be
because the flaw does not affect likely configurations, or it is a
configuration that isn’t widely used.</p></section><section>
+ <h3><a name="Low"></a>Low</h3>
+ <p>All other security flaws are classed as a Low impact. This
rating is used for issues that are believed to be extremely hard to exploit, or
where an exploit gives minimal consequences.</p></section></section>
+ </main>
-<tr class="a">
-<th> <a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a>
</th>
-<th> </th></tr>
-</thead><tbody>
-<tr class="b">
-<td> Severity </td>
-<td> Moderate </td></tr>
-<tr class="a">
-<td> CVSS Base Score </td>
-<td> 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) </td></tr>
-<tr class="b">
-<td> Versions Affected </td>
-<td> All versions from 2.0-alpha1 to 2.8.1 </td></tr>
-</tbody>
-</table><section>
-<h3><a name="Description"></a>Description</h3>
-<p>When using the TCP socket server or UDP socket server to receive serialized
log events from another application, a specially crafted binary payload can be
sent that, when deserialized, can execute arbitrary code.</p></section><section>
-<h3><a name="Mitigation"></a>Mitigation</h3>
-<p>Java 7 and above users should migrate to version 2.8.2 or avoid using the
socket server classes. Java 6 users should avoid using the TCP or UDP socket
server classes, or they can manually backport the <a class="externalLink"
href="https://github.com/apache/logging-log4j2/commit/5dcc192";>security fix
commit</a> from 2.8.2.</p></section><section>
-<h3><a name="Credit"></a>Credit</h3>
-<p>This issue was discovered by Marcio Almeida de Macedo of Red Team at
Telstra</p></section><section>
-<h3><a name="References"></a>References</h3>
-<ul>
-<li><a class="externalLink"
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645";>CVE-2017-5645</a></li>
-<li><a class="externalLink"
href="https://issues.apache.org/jira/browse/LOG4J2-1863";>LOG4J2-1863</a></li>
-<li><a class="externalLink"
href="https://github.com/apache/logging-log4j2/commit/5dcc192";>Security fix
commit</a></li>
-</ul></section></section><section>
-<h2><a name="Summary_of_security_impact_levels_for_Apache_Log4j"></a><a
name="Security_Impact_Levels"></a> Summary of security impact levels for Apache
Log4j</h2>
-<p>The Apache Log4j Security Team rates the impact of each security flaw that
affects Log4j. We’ve chosen a rating scale quite similar to those used
by other major vendors in order to be consistent. Basically the goal of the
rating system is to answer the question “How worried should I be about
this vulnerability?”.</p>
-<p>Note that the rating chosen for each flaw is the worst possible case across
all architectures. To determine the exact impact of a particular vulnerability
on your own systems you will still need to read the security advisories to find
out more about the flaw.</p>
-<p>We use the following descriptions to decide on the impact rating to give
each vulnerability:</p><section>
-<h3><a name="Critical"></a>Critical</h3>
-<p>A vulnerability rated with a Critical impact is one which could potentially
be exploited by a remote attacker to get Log4j to execute arbitrary code
(either as the user the server is running as, or root). These are the sorts of
vulnerabilities that could be exploited automatically by
worms.</p></section><section>
-<h3><a name="Important"></a>Important</h3>
-<p>A vulnerability rated as Important impact is one which could result in the
compromise of data or availability of the server. For Log4j this includes
issues that allow an easy remote denial of service (something that is out of
proportion to the attack or with a lasting consequence), access to arbitrary
files outside of the context root, or access to files that should be otherwise
prevented by limits or authentication.</p></section><section>
-<h3><a name="Moderate"></a>Moderate</h3>
-<p>A vulnerability is likely to be rated as Moderate if there is significant
mitigation to make the issue less of an impact. This might be because the flaw
does not affect likely configurations, or it is a configuration that
isn’t widely used.</p></section><section>
-<h3><a name="Low"></a>Low</h3>
-<p>All other security flaws are classed as a Low impact. This rating is used
for issues that are believed to be extremely hard to exploit, or where an
exploit gives minimal consequences.</p></section></section>
- </main>
</div>
</div>
<hr/>
