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/22 02:37:45 UTC
[logging-log4j2] branch release-2.x updated: [DOC] Update About page and Security page for release 2.3.1 and 2.12.3
This is an automated email from the ASF dual-hosted git repository.
rpopma pushed a commit to branch release-2.x
in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
The following commit(s) were added to refs/heads/release-2.x by this push:
new 4ebb401 [DOC] Update About page and Security page for release 2.3.1 and 2.12.3
4ebb401 is described below
commit 4ebb40191e3aa6c1cb52553c53d7c9da310b0382
Author: rpopma <rp...@apache.org>
AuthorDate: Wed Dec 22 11:37:38 2021 +0900
[DOC] Update About page and Security page for release 2.3.1 and 2.12.3
---
src/site/markdown/index.md.vm | 61 ++++++++--------------------------------
src/site/markdown/security.md | 65 ++++++++++++++++++++++++++++++-------------
2 files changed, 58 insertions(+), 68 deletions(-)
diff --git a/src/site/markdown/index.md.vm b/src/site/markdown/index.md.vm
index 4eae960..87672da 100644
--- a/src/site/markdown/index.md.vm
+++ b/src/site/markdown/index.md.vm
@@ -27,11 +27,10 @@ Apache Log4j 2 is an upgrade to Log4j that provides significant improvements ove
provides many of the improvements available in Logback while fixing some inherent problems in Logback's architecture.
-<a name="CVE-2021-45105"/>
-$h2 Important: Security Vulnerability CVE-2021-45105
+$h2 Important: Security Vulnerabilities CVE-2021-45105, CVE-2021-45046 and CVE-2021-44228
-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, and in Log4j 2.12.3 for Java 7.
+<a name="CVE-2021-45105"/>
+$h3 CVE-2021-45105
Summary: Apache Log4j2 does not always protect from infinite recursion in lookup evaluation.
@@ -42,23 +41,14 @@ attackers with control over Thread Context Map (MDC) input data can craft malici
resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.
$h4 Mitigation
-From version 2.17.0 (for Java 8) and 2.12.3 (for Java 7), 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.
-
-In prior releases this issue can be mitigated by ensuring your logging configuration does the following:
-
-* In PatternLayout in the logging configuration, replace Context Lookups like `${dollar}{ctx:loginId}`or `${dollar}${dollar}{ctx:loginId}` with Thread Context Map patterns (%X, %mdc, or %MDC).
-* Otherwise, in the configuration, remove references to Context Lookups like `${dollar}{ctx:loginId}` or `${dollar}${dollar}{ctx:loginId}` where they originate from sources external to the application such as HTTP headers or user input.
+Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
$h4 Reference
-Please refer to the [Security page](security.html#CVE-2021-45105) for details and mitigation measures for older versions of Log4j.
+Please refer to the [Security page](https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105) for details and mitigation measures for older versions of Log4j.
<a name="CVE-2021-45046"/>
-$h2 Important: Security Vulnerability CVE-2021-45046
-
-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.
+$h3 CVE-2021-45046
Summary: Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations.
@@ -69,34 +59,17 @@ attackers with control over Thread Context Map (MDC) input data can craft malici
resulting in an information leak and remote code execution in some environments and local code execution in all environments;
remote code execution has been demonstrated on macOS but no other tested environments.
-Note that previous mitigations involving configuration such as setting the system property `log4j2.formatMsgNoLookups`
-to `true` do NOT mitigate this specific vulnerability.
-
$h4 Mitigation
-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.
-
-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.
-
+Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
$h4 Reference
-Please refer to the [Security page](security.html#CVE-2021-45046) for details and mitigation measures for older versions of Log4j.
+Please refer to the [Security page](https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046) for details and mitigation measures for older versions of Log4j.
<a name="CVE-2021-44228"/>
-$h2 Important: Security Vulnerability CVE-2021-44228
-
-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.
+$h3 CVE-2021-44228
-$h4 Summary
+Summary:
Log4j’s JNDI support has not restricted what names could be resolved. Some protocols are unsafe or can allow remote code
execution.
@@ -108,20 +81,10 @@ that remote server. This in turn could execute any code during deserialization.
This is known as a RCE (Remote Code Execution) attack.
$h4 Mitigation
-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.
-
-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.
+Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
$h4 Reference
-Please refer to the [Security page](security.html#CVE-2021-44228) for mitigation measures for older versions of Log4j.
+Please refer to the [Security page](https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228) for details and mitigation measures for older versions of Log4j.
$h2 Features
diff --git a/src/site/markdown/security.md b/src/site/markdown/security.md
index a901c93..e201710 100644
--- a/src/site/markdown/security.md
+++ b/src/site/markdown/security.md
@@ -47,7 +47,7 @@ privately to the [Log4j Security Team](mailto:private@logging.apache.org). Thank
<a name="CVE-2021-45105"/><a name="cve-2021-45046"/>
-## <a name="log4j-2.17.0"/> Fixed in Log4j 2.17.0 (Java 8) and 2.12.3 (Java 7)
+## <a name="log4j-2.17.0"/> Fixed in Log4j 2.17.0 (Java 8), 2.12.3 (Java 7) and 2.3.1 (Java 6)
[CVE-2021-45105](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105):
Apache Log4j2 does not always protect from infinite recursion in lookup evaluation
@@ -73,12 +73,9 @@ Log4j 1.x is not impacted by this vulnerability.
#### Log4j 2.x mitigation
-Implement one of the following mitigation techniques:
-
-* Java 8 (or later) users should upgrade to release 2.17.0.
-* Java 7 users should upgrade to release 2.12.3.
+Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
-Alternatively, this can be mitigated in configuration:
+Alternatively, this infinite recursion issue can be mitigated in configuration:
* In PatternLayout in the logging configuration, replace Context Lookups like `${ctx:loginId}` or `$${ctx:loginId}` with Thread Context Map patterns (%X, %mdc, or %MDC).
* Otherwise, in the configuration, remove references to Context Lookups like `${ctx:loginId}` or `$${ctx:loginId}` where they originate
@@ -90,6 +87,18 @@ Applications using only the log4j-api JAR file without the log4j-core JAR file a
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.
+### Release Details
+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.
+
+The property to enable JNDI has been renamed from 'log4j2.enableJndi'
+to three separate properties: 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector'.
+
+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.
+
+
### Work in progress
The Log4j team will continue to actively update this page as more information becomes known.
@@ -105,7 +114,7 @@ Independently discovered by Hideki Okamoto of Akamai Technologies, Guy Lederfein
<a name="CVE-2021-45046"/><a name="cve-2021-45046"/>
-## <a name="log4j-2.16.0"/> Fixed in Log4j 2.12.2 (Java 7) and Log4j 2.16.0 (Java 8)
+## <a name="log4j-2.16.0"/> Fixed in Log4j 2.16.0 (Java 8) and Log4j 2.12.2 (Java 7)
[CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046):
Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations
@@ -133,11 +142,12 @@ Log4j 1.x is not impacted by this vulnerability.
Implement one of the following mitigation techniques:
-* Java 8 (or later) users should upgrade to release 2.16.0.
-* Java 7 users should upgrade to release 2.12.2.
+* Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
* 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`
-Users are advised not to enable JNDI in Log4j 2.16.0. If the JMS Appender is required, use Log4j 2.12.2.
+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.
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.
@@ -180,11 +190,20 @@ The safest thing to do is to upgrade Log4j to a safe version, or remove the `Jnd
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.
+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.
-From version 2.12.2 (for Java 7), the message lookups feature has been completely removed. Lookups in configuration still work.
+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.
+When enabled, JNDI will only support the JAVA protocol, support for the LDAP protocol has been removed.
+
+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.
+
+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'.
+
### Work in progress
The Log4j team will continue to actively update this page as more information becomes known.
@@ -212,7 +231,7 @@ features do not protect against attacker controlled LDAP and other JNDI related
| Versions Affected | All versions from 2.0-beta9 to 2.14.1 |
### Description
-In Apache Log4j2 versions up to and including 2.14.1 (excluding security release 2.12.2),
+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
@@ -232,8 +251,7 @@ Log4j 1.x configurations without JMSAppender are not impacted by this vulnerabil
Implement one of the following mitigation techniques:
-* Java 8 (or later) users should upgrade to release 2.16.0.
-* Java 7 users should upgrade to release 2.12.2.
+* Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
* 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`
Note that only the log4j-core JAR file is impacted by this vulnerability.
@@ -274,11 +292,20 @@ The 2.15.0 release was found to have additional vulnerabilities and is not recom
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.
+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.
-From version 2.12.2 (for Java 7), the message lookups feature has been completely removed. Lookups in configuration still work.
+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.
+When enabled, JNDI will only support the JAVA protocol, support for the LDAP protocol has been removed.
+
+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.
+
+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'.
+
### Work in progress
The Log4j team will continue to actively update this page as more information becomes known.