This is an automated email from the ASF dual-hosted git repository. vy pushed a commit to branch 2.17.1-site in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
commit 00b916b4713ef51529a18830e920c4bd0a91d6f2 Author: Ralph Goers <[email protected]> AuthorDate: Tue Dec 28 12:27:40 2021 -0700 Log4j 2.17.1 --- src/changes/announcement.vm | 12 ++------ src/changes/changes.xml | 4 +++ src/site/markdown/index.md.vm | 72 ++++++++++--------------------------------- src/site/markdown/security.md | 59 +++++++++++++++++++++++++++++++++++ 4 files changed, 82 insertions(+), 65 deletions(-) diff --git a/src/changes/announcement.vm b/src/changes/announcement.vm index 9dbeb173a4..6e7308026d 100644 --- a/src/changes/announcement.vm +++ b/src/changes/announcement.vm @@ -67,22 +67,14 @@ The artifacts may be downloaded from https://logging.apache.org/log4j/2.x/downlo This release contains the changes noted below: -* Address CVE-2021-45105. -* Require components that use JNDI to be enabled individually via system properties. -* Remove LDAP and LDAPS as supported protocols from JNDI. +* Address CVE-2021-44832. +* Other minor fixes. Due to a break in compatibility in the SLF4J binding, Log4j now ships with two versions of the SLF4J to Log4j adapters. log4j-slf4j-impl should be used with SLF4J 1.7.x and earlier and log4j-slf4j18-impl should be used with SLF4J 1.8.x and later. SLF4J-2.0.0 alpha releases are not fully supported. See https://issues.apache.org/jira/browse/LOG4J2-2975 and https://jira.qos.ch/browse/SLF4J-511. -Some of the changes in Log4j ${relVersion} include: - -* Disable recursive evaluation of Lookups during log event processing. Recursive evaluation is still allwoed while -generating the configuration. -* The JndiLookup, JndiContextSelector, and JMSAppender now require individual system properties to be enabled. -* Removed support for the LDAP and LDAPS protocols via JNDI. - The Log4j ${relVersion} API, as well as many core components, maintains binary compatibility with previous releases. ## Hack to improve layout: replace all pairs of spaces with a single new-line diff --git a/src/changes/changes.xml b/src/changes/changes.xml index fdfc8d2513..a25e90c290 100644 --- a/src/changes/changes.xml +++ b/src/changes/changes.xml @@ -31,6 +31,10 @@ --> <release version="2.17.1" date="2021-12-27" description="GA Release 2.17.1"> <!-- FIXES --> + <action issue="LOG4J2-3293" dev="ggregory" type="fix"> + JdbcAppender now uses JndiManager to access JNDI resources. JNDI is only enabled when system property + log4j2.enableJndiJdbc is set to true. + </action> <action issue="LOG4J2-3290" dev="rogers" type="fix"> Remove unused method. </action> diff --git a/src/site/markdown/index.md.vm b/src/site/markdown/index.md.vm index 05e6a9c472..44d7b45a10 100644 --- a/src/site/markdown/index.md.vm +++ b/src/site/markdown/index.md.vm @@ -26,66 +26,29 @@ $h1 Apache Log4j 2 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. +<a name="CVE-2021-44832"/> +$h2 Important: Security Vulnerability CVE-2021-44832 -$h2 Important: Security Vulnerabilities CVE-2021-45105, CVE-2021-45046 and CVE-2021-44228 - -<a name="CVE-2021-45105"/> -$h3 CVE-2021-45105 - -Summary: Apache Log4j2 does not always protect from infinite recursion in lookup evaluation. +Summary: Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration. $h4 Details -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, ``${dollar}${dollar}{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) attack. - -$h4 Mitigation -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. - - -<a name="CVE-2021-45046"/> -$h3 CVE-2021-45046 - -Summary: Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations. -$h4 Details -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, ``${dollar}${dollar}{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 environments; -remote code execution has been demonstrated on macOS but no other tested environments. +Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to +a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can +construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute +remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, +2.12.4, and 2.3.2. $h4 Mitigation -Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later). +Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (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. - - -<a name="CVE-2021-44228"/> -$h3 CVE-2021-44228 - -Summary: -Log4j’s JNDI support has not restricted what names could be resolved. Some protocols are unsafe or can allow remote code -execution. - -$h4 Details -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) attack. - -$h4 Mitigation -Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later). +Please refer to the [Security page](security.html#CVE-2021-44832) for details and mitigation measures for older +versions of Log4j. -$h4 Reference -Please refer to the [Security page](security.html#CVE-2021-44228) for details and mitigation measures for older versions of Log4j. +$h2 Important: Security Vulnerabilities CVE-2021-45105, CVE-2021-45046 and CVE-2021-44228 +Please refer to the [Security page](security.html) for details and mitigation measures for these security issues. $h2 Features @@ -200,13 +163,12 @@ dependencies. $h2 News -Log4j 2.17.0 and 2.12.3 have been released solely to: +Log4j 2.17.1has been released to: -* Address CVE-2021-45105. -* Require components that use JNDI to be enabled individually via system properties. -* Remove LDAP and LDAPS as supported protocols from JNDI. +* Address CVE-2021-44832. +* Other minor bug fixes. -2.17.0 (for Java 8) and 2.12.3 (for Java 7) are recommended upgrades to ensure that recursive lookups do not cause services to fail. +2.17.1 (for Java 8) is a recommended upgrade. Log4j $Log4jReleaseVersion is now available for production. The API for Log4j 2 is not compatible with Log4j 1.x, however an adapter is available to allow applications to continue to use the Log4j 1.x API. Adapters are also available for Apache Commons diff --git a/src/site/markdown/security.md b/src/site/markdown/security.md index 2887ec0d7a..8555695e8f 100644 --- a/src/site/markdown/security.md +++ b/src/site/markdown/security.md @@ -45,6 +45,65 @@ If you have encountered an unlisted security vulnerability or other unexpected b that has security impact, or if the descriptions here are incomplete, please report them privately to the [Log4j Security Team](mailto:[email protected]). Thank you. +<a name="CVE-2021-44832"/><a name="cve-2021-44832"/> +## <a name="log4j-2.17.1"/> Fixed in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6) + +[CVE-2021-44832](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832): +Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration. + +| [CVE-2021-44832](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832) | Remote Code Execution | +| --------------- | -------- | +| Severity | Moderate | +| Base CVSS Score | 6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H) | +| Versions Affected | All versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4 | + +### Description +Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to +a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can +construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute +remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, +2.12.4, and 2.3.2. + + +### Mitigation + +#### Log4j 1.x mitigation + +Log4j 1.x is not impacted by this vulnerability. + +#### Log4j 2.x mitigation + +Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later). + +In prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol +other than Java. + +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. + +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.1, (and 2.12.4 and 2.3.2 for Java 7 and Java 6), +the JDBC Appender will use JndiManager and will require the `log4j2.enableJndiJdbc` system property to contain +a value of true for JNDI to be enabled. + +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. + +### Credit +No credit is being awarded for this issue. + +### References +- [CVE-2021-44832](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832) <a name="CVE-2021-45105"/><a name="cve-2021-45046"/> ## <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)
