You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@logging.apache.org by vy...@apache.org on 2023/11/06 19:54:34 UTC
(logging-log4j2) branch security-page created (now b8f22dc5dc)
This is an automated email from the ASF dual-hosted git repository.
vy pushed a change to branch security-page
in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
at b8f22dc5dc Add the forgotten CVE-2021-45105 entry (#1707)
This branch includes the following new commits:
new 54881bff0c Initial security page refactoring (#1707)
new 72cc893e87 Switch to using NVD and CVSS 3.x (#1707)
new 1167a2a7df Add sub-entries to the `Security` menu entry (#1707)
new b8f22dc5dc Add the forgotten CVE-2021-45105 entry (#1707)
The 4 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
(logging-log4j2) 01/04: Initial security page refactoring (#1707)
Posted by vy...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
vy pushed a commit to branch security-page
in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
commit 54881bff0cd81a112e9988458f29d6c2a82e86ee
Author: Volkan Yazıcı <vo...@yazi.ci>
AuthorDate: Mon Nov 6 15:42:23 2023 +0100
Initial security page refactoring (#1707)
---
src/assembly/site.xml | 31 ---
src/site/asciidoc/_log4j1-eol.adoc | 23 ++
src/site/asciidoc/security.adoc | 325 +++++++++++++++++++++++
src/site/markdown/security.md | 514 -------------------------------------
src/site/site.xml | 8 +-
5 files changed, 355 insertions(+), 546 deletions(-)
diff --git a/src/assembly/site.xml b/src/assembly/site.xml
deleted file mode 100644
index 88292eb292..0000000000
--- a/src/assembly/site.xml
+++ /dev/null
@@ -1,31 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!--
- ~ 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
- ~
- ~ 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.
- -->
-<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
- <id>site</id>
- <formats>
- <format>zip</format>
- </formats>
- <fileSets>
- <fileSet>
- <directory>${stagingSiteURL}</directory>
- <outputDirectory>${stagingSiteURL}</outputDirectory>
- </fileSet>
- </fileSets>
-</assembly>
diff --git a/src/site/asciidoc/_log4j1-eol.adoc b/src/site/asciidoc/_log4j1-eol.adoc
new file mode 100644
index 0000000000..7c72ed846d
--- /dev/null
+++ b/src/site/asciidoc/_log4j1-eol.adoc
@@ -0,0 +1,23 @@
+////
+ 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
+
+ https://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.
+////
+
+[WARNING]
+====
+http://logging.apache.org/log4j/1.x[Log4j 1] has https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces[reached End of Life] in 2015, and is no longer supported.
+Vulnerabilities reported after August 2015 against Log4j 1 are not checked and will not be fixed.
+Users should xref:manual/migration.html[upgrade to Log4j 2] to obtain security fixes.
+====
diff --git a/src/site/asciidoc/security.adoc b/src/site/asciidoc/security.adoc
new file mode 100644
index 0000000000..00171cb682
--- /dev/null
+++ b/src/site/asciidoc/security.adoc
@@ -0,0 +1,325 @@
+////
+ 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
+
+ https://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.
+////
+
+= Security
+
+The Apache Log4j Security Team takes security seriously.
+This allows our users to place their trust in Log4j for protecting their mission-critical data.
+In this page we will help you find guidance on security-related issues and access to known vulnerabilities.
+
+include::_log4j1-eol.adoc[]
+
+[#support]
+== Getting support
+
+If you need help on building or configuring Log4j or other help on following the instructions to mitigate the known vulnerabilities listed here, please use our xref:support.adoc#discussions[user support channels].
+
+[TIP]
+====
+If you need to apply a source code patch, use the building instructions for the Log4j version that you are using.
+These instructions can be found in `BUILDING.md` distributed with the sources.
+====
+
+[#reporting]
+== Reporting vulnerabilities
+
+If you have encountered an unlisted security vulnerability or other unexpected behaviour that has a security impact, or if the descriptions here are incomplete, please report them **privately** to mailto:security@logging.apache.org[the Log4j Security Team].
+
+[WARNING]
+====
+Reports assuming attacker's access to the Log4j configuration will not qualify as a vulnerability.
+====
+
+[#policy]
+== Vulnerability handling policy
+
+The Apache Log4j Security Team follows the https://www.apache.org/security/committers.html[ASF Project Security] guide for handling security vulnerabilities.
+
+Found security vulnerabilities are subject to voting (by means of https://logging.apache.org/guidelines.html[_lazy approval_], preferably) in the private mailto:security@logging.apache.org[security mailing list] before creating a CVE and populating its associated content.
+This procedure involves only the creation of CVEs and blocks neither (vulnerability) fixes, nor releases.
+
+[#Security_Impact_Levels]
+== Impact levels
+
+The Apache Log4j Security Team rates the impact of each security flaw that affects Log4j.
+We have 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 of _"How worried should I be about this vulnerability?"_.
+
+Note that the rating may vary from platform to platform and 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.
+
+We use the following descriptions to decide on the impact rating to give each vulnerability:
+
+[cols="1,2",options="header"]
+|===
+|Severity|https://www.first.org/cvss/calculator/3.0[CVSS v3 Score Range]
+|Critical|9.0 - 10.0
+|High|7.0 - 8.9
+|Moderate|4.0 - 6.9
+|Low|0.1 - 3.9
+|===
+
+[#impact-level-critical]
+=== Critical
+
+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.
+
+[#impact-level-high]
+=== High
+
+A vulnerability rated as _high_ 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 the context root, or access to files that should be otherwise prevented by limits or authentication.
+
+[#impact-level-moderate]
+=== Moderate
+
+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.
+
+[#impact-level-low]
+=== Low
+
+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.
+
+[#vulnerabilities]
+== Known vulnerabilities
+
+The Log4j Security Team believes that accuracy, completeness and availability of security information is essential for our users.
+We choose to pool all information on this one page, allowing easy searching for security vulnerabilities over a range of criteria.
+
+[#CVE-2021-44832]
+=== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832[CVE-2021-44832]
+
+[cols="1h,5"]
+|===
+|Summary |Infinite recursion in lookup evaluation
+|Type |Denial-of-Service
+|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-alpha1` to `2.16.0` (excluding `2.3.1` and `2.12.3`)
+|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later)
+|===
+
+[#CVE-2021-44832-description]
+==== Description
+
+Log4j versions `2.0-alpha1` through `2.16.0` (excluding `2.3.1` and `2.12.3`), did not protect from uncontrolled recursion that can be implemented using 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)_ attack.
+
+[#CVE-2021-44832-mitigation]
+==== Mitigation
+
+Upgrade to `2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later).
+
+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
+from sources external to the application such as HTTP headers or user input.
+Note that this mitigation is insufficient in releases older than `2.12.2` (for Java 7), and `2.16.0` (for Java 8 and later) as the issues fixed in those releases will still be present.
+
+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.
+
+[#CVE-2021-44832-credits]
+==== Credits
+
+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.
+
+[#CVE-2021-44832-references]
+==== References
+
+- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105[CVE-2021-45105]
+- https://issues.apache.org/jira/browse/LOG4J2-3230[LOG4J2-3230]
+
+[#CVE-2021-45046]
+=== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046[CVE-2021-45046]
+
+[cols="1h,5"]
+|===
+|Summary |Thread Context Lookup is vulnerable to remote code execution in certain non-default configurations
+|Type |Remote Code Execution
+|Severity |Critical
+|Base CVSS score |9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
+|Versions affected |all versions from `2.0-beta9` to `2.15.0` (excluding `2.3.1` and `2.12.3`)
+|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later)
+|===
+
+[#CVE-2021-45046-description]
+==== Description
+
+It was found that the fix to address <<CVE-2021-44228>> in Log4j `2.15.0` was incomplete in certain non-default configurations.
+When the logging configuration uses a non-default Pattern Layout with a Thread Context Lookup (for example, `$${ctx:loginId}`), attackers with control over Thread Context Map (MDC) 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, Fedora, Arch Linux, and Alpine Linux.
+
+Note that this vulnerability is not limited to just the JNDI lookup.
+Any other Lookup could also be included in a Thread Context Map variable and possibly have private details exposed to anyone with access to the logs.
+
+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.
+
+[#CVE-2021-45046-mitigation]
+==== 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).
+
+[#CVE-2021-45046-credits]
+==== Credits
+
+This issue was discovered by Kai Mindermann of iC Consult and separately by 4ra1n.
+
+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).
+
+[#CVE-2021-45046-references]
+==== References
+
+- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046[CVE-2021-45046]
+- https://issues.apache.org/jira/browse/LOG4J2-3221[LOG4J2-3221]
+
+[#CVE-2021-44228]
+=== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228[CVE-2021-44228]
+
+[cols="1h,5"]
+|===
+|Summary |JNDI lookup can be exploited to execute arbitrary code loaded from an LDAP server
+|Type |Remote Code Execution
+|Severity |Critical
+|Base CVSS score |10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
+|Versions affected |all versions from `2.0-beta9` to `2.14.1` (excluding `2.3.1` and `2.12.3`)
+|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later)
+|===
+
+[#CVE-2021-44228-description]
+==== Description
+
+In Log4j, 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.
+
+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.
+
+[#CVE-2021-44228-mitigation]
+==== Mitigation
+
+[#CVE-2021-44228-mitigation-log4j1]
+===== Log4j 1 mitigation
+
+include::_log4j1-eol.adoc[]
+
+Log4j 1 does not have Lookups, so the risk is lower.
+Applications using Log4j 1 are only vulnerable to this attack when they use JNDI in their configuration.
+A separate CVE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104[CVE-2021-4104]) has been filed for this vulnerability.
+To mitigate, audit your logging configuration to ensure it has no `JMSAppender` configured.
+Log4j 1 configurations without `JMSAppender` are not impacted by this vulnerability.
+
+[#CVE-2021-44228-mitigation-log4j2]
+===== Log4j 2 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).
+
+[#CVE-2021-44228-credits]
+==== Credits
+
+This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
+
+[#CVE-2021-44228-references]
+==== References
+
+- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228[CVE-2021-44228]
+- https://issues.apache.org/jira/browse/LOG4J2-3198[LOG4J2-3198]
+- https://issues.apache.org/jira/browse/LOG4J2-3201[LOG4J2-3201]
+
+[#CVE-2020-9488]
+=== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488[CVE-2020-9488]
+
+[cols="1h,5"]
+|===
+|Summary |Improper validation of certificate with host mismatch in SMTP appender
+|Severity |Low
+|Base CVSS score |3.7 (Low) CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
+|Versions affected |all versions from `2.0-beta1` to `2.13.1` (excluding `2.3.1` and `2.12.3`)
+|Versions fixed |`2.12.3` (Java 7) and `2.13.2` (Java 8)
+|===
+
+[#CVE-2020-9488-description]
+==== Description
+
+Improper validation of certificate with host mismatch in 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.
+
+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.
+
+[#CVE-2020-9488-mitigation]
+==== Mitigation
+
+Upgrade to `2.12.3` (Java 7) or `2.13.2` (Java 8).
+
+Alternatively, users can set the `mail.smtp.ssl.checkserveridentity` system property to `true` to enable SMTPS hostname verification for all SMTPS mail sessions.
+
+[#CVE-2020-9488-credits]
+==== Credits
+
+This issue was discovered by Peter Stöckli.
+
+[#CVE-2020-9488-references]
+==== References
+
+- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488[CVE-2020-9488]
+- https://issues.apache.org/jira/browse/LOG4J2-2819[LOG4J2-2819]
+
+[#CVE-2017-5645]
+=== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645[CVE-2017-5645]
+
+[cols="1h,5"]
+|===
+|Summary |TCP/UDP socket servers can be exploited to execute arbitrary code
+|Type |Remote Code Execution
+|Severity |Moderate
+|Base CVSS score |7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
+|Versions affected |all versions from `2.0-alpha1` to `2.8.1`
+|Versions fixed |`2.8.2` (Java 7)
+|===
+
+[#CVE-2017-5645-description]
+==== Description
+
+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.
+
+[#CVE-2017-5645-mitigation]
+==== Mitigation
+
+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 https://github.com/apache/logging-log4j2/commit/5dcc192[the security fix commit] from `2.8.2`.
+
+[#CVE-2017-5645-credits]
+==== Credits
+
+This issue was discovered by Marcio Almeida de Macedo of Red Team at Telstra.
+
+[#CVE-2017-5645-references]
+==== References
+
+- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645[CVE-2017-5645]
+- https://issues.apache.org/jira/browse/LOG4J2-1863[LOG4J2-1863]
+- https://github.com/apache/logging-log4j2/commit/5dcc192[Security fix commit]
diff --git a/src/site/markdown/security.md b/src/site/markdown/security.md
deleted file mode 100644
index 2b5d7386cd..0000000000
--- a/src/site/markdown/security.md
+++ /dev/null
@@ -1,514 +0,0 @@
-<!-- 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
-
- 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.
--->
-
-# Apache Log4j Security Vulnerabilities
-
-This page lists all the security vulnerabilities fixed in released versions of Apache Log4j 2.
-Each vulnerability is given a [security impact rating](#Security_Impact_Levels)
-by the [Apache Logging security team](mailto:security@logging.apache.org).
-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 a question mark.
-
-[Log4j 1.x](http://logging.apache.org/log4j/1.2/) has
-[reached End of Life](https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces)
-in 2015 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](manual/migration.html) to obtain security fixes.
-
-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 these can be found in `BUILDING.md` located in the root subdirectory of the source distribution.
-
-If you need help on building or configuring Log4j or other help on following the instructions
-to mitigate the known vulnerabilities listed here, please
-[subscribe to](mailto:log4j-user-subscribe@logging.apache.org), and send your questions to the public
-Log4j [Users mailing list](mail-lists.html).
-
-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 Log4j Security Team](mailto:security@logging.apache.org).
-Note that reports assuming attacker's access to the Log4j configuration will not qualify as a vulnerability.
-Thank you for your understanding and help!
-
-<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-beta7 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)
-
-[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
-
-| [CVE-2021-45105](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105) | Denial of Service |
-| --------------- | -------- |
-| Severity | Moderate |
-| Base CVSS Score | 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) |
-| Versions Affected | All versions from 2.0-alpha1 to 2.16.0, excluding 2.12.3 |
-
-### Description
-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 known as a DOS (Denial of Service) attack.
-
-
-### Mitigation
-
-#### Log4j 1.x mitigation
-
-Log4j 1.x is not impacted by this vulnerability.
-
-#### Log4j 2.x 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).
-
-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
-from sources external to the application such as HTTP headers or user input. Note that this mitigation is insufficient in
-releases older than 2.12.2 (Java 7), and 2.16.0 (Java 8 and later) as the issues fixed in those releases will
-still be present.
-
-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.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.
-
-### Credit
-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.
-
-### References
-- [CVE-2021-45105](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105)
-- [LOG4J2-3230](https://issues.apache.org/jira/browse/LOG4J2-3230)
-
-
-
-
-
-<a name="CVE-2021-45046"/><a name="cve-2021-45046"/>
-## <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
-
-| [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046) | Remote Code Execution |
-| --------------- | -------- |
-| Severity | Critical |
-| Base CVSS Score | 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) |
-| Versions Affected | All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 |
-
-### Description
-It was found that the fix to address [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 environments;
-remote code execution has been demonstrated on macOS, Fedora, Arch Linux, and Alpine Linux.
-
-Note that this vulnerability is not limited to just the JDNI lookup. Any other Lookup could also be included in a
-Thread Context Map variable and possibly have private details exposed to anyone with access to the logs.
-
-### Mitigation
-
-#### Log4j 1.x mitigation
-
-Log4j 1.x is not impacted by this vulnerability.
-
-#### Log4j 2.x mitigation
-
-Implement one of the following mitigation techniques:
-
-* 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 that while removing the JndiLookup class prevents a potential RCE from occuring, it still leaves
-the application vulnerable to other misuse of Lookups in Thread Context Map data. While the mitigations listed below in
-the history section help in some situations, the only real solution is to upgarde to one of the releases listed in the
-first bullet above (or a newer release).
-
-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.
-
-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.
-
-### History
-**Severity is now Critical**
-
-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.
-
-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).
-
-The title of this CVE was changed from mentioning Denial of Service attacks to mentioning Remote Code Execution attacks.
-
-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.
-
-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.
-
-
-**Older (discredited) mitigation measures**
-
-This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open.
-
-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.
-
-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.
-
-The safest thing to do is to upgrade Log4j to a safe version, or remove the `JndiLookup` class from the log4j-core jar.
-
-### Release Details
-
-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 the JAVA protocol is supported in JNDI connections.
-
-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.
-
-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.
-
-### Credit
-This issue was discovered by Kai Mindermann of iC Consult and separately by 4ra1n.
-
-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).
-
-### References
-- [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046)
-- [LOG4J2-3221](https://issues.apache.org/jira/browse/LOG4J2-3221)
-
-
-<a name="CVE-2021-44228"/><a name="cve-2021-44228"/>
-## <a name="log4j-2.15.0"/> Fixed in Log4j 2.15.0 (Java 8)
-
-[CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228): Apache Log4j2 JNDI
-features do not protect against attacker controlled LDAP and other JNDI related endpoints. Log4j2 allows
-Lookup expressions in the data being logged exposing the JNDI vulnerability, as well as other problems,
-to be exploited by end users whose input is being logged.
-
-|[CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) | Remote Code Execution |
-| ----------------- | -------- |
-| Severity | Critical |
-| Base CVSS Score | 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
-| 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 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.
-
-### Mitigation
-
-#### Log4j 1.x mitigation
-
-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.
-
-#### Log4j 2.x mitigation
-
-Implement one of the following mitigation techniques:
-
-* 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 simply removing the JndiLookup only resolves one of the two bugs exposed in CVE-2021-44228. This still
-allows users to enter lookup strings into input fields and cause them to be evaluated, which can cause StackOverflowExceptions
-or potentially expose private data to anyone provided access to the logs. While the mitigations listed below in the
-history section help in some situations, the only real solution is to upgarde to one of the releases listed in the
-first bullet above (or a newer release).
-
-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.
-
-### History
-#### Older (discredited) mitigation measures
-
-This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open.
-
-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.
-
-A new CVE (CVE-2021-45046, see above) was raised for this.
-
-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.
-
-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.
-
-The safest thing to do is to upgrade Log4j to a safe version, or remove the `JndiLookup` class from the log4j-core jar.
-
-#### Release Details
-
-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.
-
-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 the JAVA protocol is supported in JNDI connections.
-
-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.
-
-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.
-
-### Credit
-This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
-
-### References
-- [https://issues.apache.org/jira/browse/LOG4J2-3201](https://issues.apache.org/jira/browse/LOG4J2-3201)
-- [https://issues.apache.org/jira/browse/LOG4J2-3198](https://issues.apache.org/jira/browse/LOG4J2-3198).
-
-## <a name="log4j-2.13.2"/> Fixed in Log4j 2.13.2 (Java 8) and 2.12.3 (Java 7)
-<a name="CVE-2020-9488"/><a name="cve-2020-9488"/>
-[CVE-2020-9488](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488): Improper validation of certificate with host mismatch in Apache Log4j SMTP appender.
-
-| [CVE-2020-9488](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488) | |
-| ----------------- | --- |
-| Severity | Low |
-| CVSS Base Score | 3.7 (Low) CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N |
-| Versions Affected | All versions from 2.0-alpha1 to 2.13.1 |
-
-### Description
-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.
-
-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.
-
-### Mitigation
-Users should upgrade to Apache Log4j 2.13.2 which fixed this issue in
-[https://issues.apache.org/jira/browse/LOG4J2-2819](https://issues.apache.org/jira/browse/LOG4J2-2819)
-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.
-
-### Credit
-This issue was discovered by Peter Stöckli.
-
-### References
-- [CVE-2020-9488](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488)
-- [LOG4J2-2819](https://issues.apache.org/jira/browse/LOG4J2-2819)
-
-
-## <a name="log4j-2.8.2"/> Fixed in Log4j 2.8.2 (Java 7)
-<a name="CVE-2017-5645"/><a name="cve-2017-5645"/>
-[CVE-2017-5645](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645): Apache Log4j socket receiver deserialization vulnerability.
-
-| [CVE-2017-5645](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645) | |
-| ----------------- | -------- |
-| Severity | Moderate |
-| CVSS Base Score | 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) |
-| Versions Affected | All versions from 2.0-alpha1 to 2.8.1 |
-
-### Description
-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.
-
-### Mitigation
-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
-[security fix commit](https://github.com/apache/logging-log4j2/commit/5dcc192) from
-2.8.2.
-
-### Credit
-This issue was discovered by Marcio Almeida de Macedo of Red Team
-at Telstra
-
-### References
-- [CVE-2017-5645](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645)
-- [LOG4J2-1863](https://issues.apache.org/jira/browse/LOG4J2-1863)
-- [Security fix commit](https://github.com/apache/logging-log4j2/commit/5dcc192)
-
-## <a name="Security_Impact_Levels"></a> Summary of security impact levels for Apache Log4j
-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?".
-
-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.
-
-We use the following descriptions to decide on the impact rating to give each vulnerability:
-
-| Severity | CVSS v3 Score Range |
-| -------- | ------------------- |
-| Critical | 9.0 - 10.0 |
-| High | 7.0 - 8.9 |
-| Moderate | 4.0 - 6.9 |
-| Low | 0.1 - 3.9 |
-
-### Critical
-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. Critical vulnerabilities score between 9.0 and 10.0 on the
-[CVSS v3 calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator).
-
-### High
-A vulnerability rated as High 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. High vulnerabilities score between 7.0 and 8.9 on the
-[CVSS v3 calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator).
-
-### Moderate
-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. Moderate vulnerabilities score between 4.0 and 6.9 on the
-[CVSS v3 calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator).
-
-### Low
-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. Low vulnerabilities
-score between 0.1 and 3.9 on the [CVSS v3 calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator).
-
-## <a name="cve-creation"></a> CVE creation process
-
-Found security vulnerabilities are subject to voting (by means of [_lazy approval_](https://logging.apache.org/guidelines.html), preferably) in the private [security mailing list](mailto:security@logging.apache.org) before creating a CVE and populating its associated content.
-This procedure involves only the creation of CVEs and blocks neither (vulnerability) fixes, nor releases.
diff --git a/src/site/site.xml b/src/site/site.xml
index 3eda6908ef..786061835a 100644
--- a/src/site/site.xml
+++ b/src/site/site.xml
@@ -69,7 +69,13 @@
<item name="Trade-offs" href="/performance.html#tradeoffs" />
</item>
<item name="Articles and Tutorials" href="/articles.html"/>
- <item name="Security" href="/security.html"/>
+ <item name="Security" href="/security.html">
+ <item name="Getting support" href="/security.html#support" />
+ <item name="Reporting vulnerabilities" href="/security.html#reporting" />
+ <item name="Vulnerability handling policy" href="/security.html#policy" />
+ <item name="Impact levels" href="/security.html#Security_Impact_Levels" />
+ <item name="Known Vulnerabilities" href="/security.html#vulnerabilities" />
+ </item>
</menu>
<menu name="Manual" inherit="top" img="img/glyphicons/book.png">
(logging-log4j2) 04/04: Add the forgotten CVE-2021-45105 entry (#1707)
Posted by vy...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
vy pushed a commit to branch security-page
in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
commit b8f22dc5dcc2b77229e061ae627c89f640174b24
Author: Volkan Yazıcı <vo...@yazi.ci>
AuthorDate: Mon Nov 6 20:54:26 2023 +0100
Add the forgotten CVE-2021-45105 entry (#1707)
---
src/site/asciidoc/security.adoc | 58 ++++++++++++++++++++++++++++++++---------
1 file changed, 46 insertions(+), 12 deletions(-)
diff --git a/src/site/asciidoc/security.adoc b/src/site/asciidoc/security.adoc
index 7684aa1e75..054392eafc 100644
--- a/src/site/asciidoc/security.adoc
+++ b/src/site/asciidoc/security.adoc
@@ -63,22 +63,52 @@ We choose to pool all information on this one page, allowing easy searching for
[#CVE-2021-44832]
=== {cve-url-prefix}/CVE-2021-44832[CVE-2021-44832]
+[cols="1h,5"]
+|===
+|Summary |JDBC appender is vulnerable to remote code execution in certain configurations
+|CVSS 3.x Score & Vector |6.6 MEDIUM (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
+|Components affected |`log4j-core`
+|Versions affected |all versions from `2.0-beta7` to `2.17.0`
+|Versions fixed |`2.3.2` (for Java 6), `2.12.4` (for Java 7), or `2.17.1` (for Java 8 and later)
+|===
+
+[#CVE-2021-44832-description]
+==== Description
+
+An attacker with write access to the logging configuration 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.
+
+[#CVE-2021-44832-mitigation]
+==== Mitigation
+
+Upgrade to `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`.
+
+[#CVE-2021-44832-references]
+==== References
+- {cve-url-prefix}/CVE-2021-44832[CVE-2021-44832]
+
+[#CVE-2021-45105]
+=== {cve-url-prefix}/CVE-2021-45105[CVE-2021-45105]
+
[cols="1h,5"]
|===
|Summary |Infinite recursion in lookup evaluation
-|CVSS 3.x Score & Vector |6.6 MEDIUM (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
+|CVSS 3.x Score & Vector |5.9 MEDIUM (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
+|Components affected |`log4j-core`
|Versions affected |all versions from `2.0-alpha1` to `2.16.0` (excluding `2.3.1` and `2.12.3`)
|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later)
|===
-[#CVE-2021-44832-description]
+[#CVE-2021-45105-description]
==== Description
Log4j versions `2.0-alpha1` through `2.16.0` (excluding `2.3.1` and `2.12.3`), did not protect from uncontrolled recursion that can be implemented using 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)_ attack.
-[#CVE-2021-44832-mitigation]
+[#CVE-2021-45105-mitigation]
==== Mitigation
Upgrade to `2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later).
@@ -93,12 +123,12 @@ Note that this mitigation is insufficient in releases older than `2.12.2` (for J
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.
-[#CVE-2021-44832-credits]
+[#CVE-2021-45105-credits]
==== Credits
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.
-[#CVE-2021-44832-references]
+[#CVE-2021-45105-references]
==== References
- {cve-url-prefix}/CVE-2021-45105[CVE-2021-45105]
@@ -109,8 +139,9 @@ Independently discovered by Hideki Okamoto of Akamai Technologies, Guy Lederfein
[cols="1h,5"]
|===
-|Summary |Thread Context Lookup is vulnerable to remote code execution in certain non-default configurations
-|CVSS 3.x Score & Vector |9.0 CRITICAL (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
+|Summary |Thread Context Lookup is vulnerable to remote code execution in certain configurations
+|CVSS 3.x Score & Vector |9.0 CRITICAL (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
+|Components affected |`log4j-core`
|Versions affected |all versions from `2.0-beta9` to `2.15.0` (excluding `2.3.1` and `2.12.3`)
|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later)
|===
@@ -152,7 +183,8 @@ Additional vulnerability details discovered independently by Ash Fox of Google,
[cols="1h,5"]
|===
|Summary |JNDI lookup can be exploited to execute arbitrary code loaded from an LDAP server
-|CVSS 3.x Score & Vector |10.0 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
+|CVSS 3.x Score & Vector |10.0 CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
+|Components affected |`log4j-core`
|Versions affected |all versions from `2.0-beta9` to `2.14.1` (excluding `2.3.1` and `2.12.3`)
|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later)
|===
@@ -203,9 +235,10 @@ This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
[cols="1h,5"]
|===
|Summary |Improper validation of certificate with host mismatch in SMTP appender
-|CVSS 3.x Score & Vector |3.7 LOW (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N)
+|CVSS 3.x Score & Vector |3.7 LOW (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N)
+|Components affected |`log4j-core`
|Versions affected |all versions from `2.0-beta1` to `2.13.1` (excluding `2.3.1` and `2.12.3`)
-|Versions fixed |`2.12.3` (Java 7) and `2.13.2` (Java 8)
+|Versions fixed |`2.12.3` (Java 7) and `2.13.2` (Java 8 and later)
|===
[#CVE-2020-9488-description]
@@ -223,7 +256,7 @@ Usages of `SslConfiguration` that are configured via system properties are not a
[#CVE-2020-9488-mitigation]
==== Mitigation
-Upgrade to `2.12.3` (Java 7) or `2.13.2` (Java 8).
+Upgrade to `2.12.3` (Java 7) or `2.13.2` (Java 8 and later).
Alternatively, users can set the `mail.smtp.ssl.checkserveridentity` system property to `true` to enable SMTPS hostname verification for all SMTPS mail sessions.
@@ -244,7 +277,8 @@ This issue was discovered by Peter Stöckli.
[cols="1h,5"]
|===
|Summary |TCP/UDP socket servers can be exploited to execute arbitrary code
-|CVSS 3.x Score & Vector |9.8 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
+|CVSS 3.x Score & Vector |9.8 CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
+|Components affected |`log4j-core`
|Versions affected |all versions from `2.0-alpha1` to `2.8.1`
|Versions fixed |`2.8.2` (Java 7)
|===
(logging-log4j2) 02/04: Switch to using NVD and CVSS 3.x (#1707)
Posted by vy...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
vy pushed a commit to branch security-page
in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
commit 72cc893e8727397517d269fbda2249d2039fde27
Author: Volkan Yazıcı <vo...@yazi.ci>
AuthorDate: Mon Nov 6 20:19:14 2023 +0100
Switch to using NVD and CVSS 3.x (#1707)
---
src/site/asciidoc/security.adoc | 90 +++++++++--------------------------------
1 file changed, 19 insertions(+), 71 deletions(-)
diff --git a/src/site/asciidoc/security.adoc b/src/site/asciidoc/security.adoc
index 00171cb682..7684aa1e75 100644
--- a/src/site/asciidoc/security.adoc
+++ b/src/site/asciidoc/security.adoc
@@ -15,6 +15,8 @@
limitations under the License.
////
+:cve-url-prefix: https://nvd.nist.gov/vuln/detail
+
= Security
The Apache Log4j Security Team takes security seriously.
@@ -52,51 +54,6 @@ The Apache Log4j Security Team follows the https://www.apache.org/security/commi
Found security vulnerabilities are subject to voting (by means of https://logging.apache.org/guidelines.html[_lazy approval_], preferably) in the private mailto:security@logging.apache.org[security mailing list] before creating a CVE and populating its associated content.
This procedure involves only the creation of CVEs and blocks neither (vulnerability) fixes, nor releases.
-[#Security_Impact_Levels]
-== Impact levels
-
-The Apache Log4j Security Team rates the impact of each security flaw that affects Log4j.
-We have 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 of _"How worried should I be about this vulnerability?"_.
-
-Note that the rating may vary from platform to platform and 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.
-
-We use the following descriptions to decide on the impact rating to give each vulnerability:
-
-[cols="1,2",options="header"]
-|===
-|Severity|https://www.first.org/cvss/calculator/3.0[CVSS v3 Score Range]
-|Critical|9.0 - 10.0
-|High|7.0 - 8.9
-|Moderate|4.0 - 6.9
-|Low|0.1 - 3.9
-|===
-
-[#impact-level-critical]
-=== Critical
-
-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.
-
-[#impact-level-high]
-=== High
-
-A vulnerability rated as _high_ 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 the context root, or access to files that should be otherwise prevented by limits or authentication.
-
-[#impact-level-moderate]
-=== Moderate
-
-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.
-
-[#impact-level-low]
-=== Low
-
-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.
-
[#vulnerabilities]
== Known vulnerabilities
@@ -104,14 +61,12 @@ The Log4j Security Team believes that accuracy, completeness and availability of
We choose to pool all information on this one page, allowing easy searching for security vulnerabilities over a range of criteria.
[#CVE-2021-44832]
-=== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832[CVE-2021-44832]
+=== {cve-url-prefix}/CVE-2021-44832[CVE-2021-44832]
[cols="1h,5"]
|===
|Summary |Infinite recursion in lookup evaluation
-|Type |Denial-of-Service
-|Severity |Moderate
-|Base CVSS score |6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
+|CVSS 3.x Score & Vector |6.6 MEDIUM (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
|Versions affected |all versions from `2.0-alpha1` to `2.16.0` (excluding `2.3.1` and `2.12.3`)
|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later)
|===
@@ -146,18 +101,16 @@ Independently discovered by Hideki Okamoto of Akamai Technologies, Guy Lederfein
[#CVE-2021-44832-references]
==== References
-- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105[CVE-2021-45105]
+- {cve-url-prefix}/CVE-2021-45105[CVE-2021-45105]
- https://issues.apache.org/jira/browse/LOG4J2-3230[LOG4J2-3230]
[#CVE-2021-45046]
-=== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046[CVE-2021-45046]
+=== {cve-url-prefix}/CVE-2021-45046[CVE-2021-45046]
[cols="1h,5"]
|===
|Summary |Thread Context Lookup is vulnerable to remote code execution in certain non-default configurations
-|Type |Remote Code Execution
-|Severity |Critical
-|Base CVSS score |9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
+|CVSS 3.x Score & Vector |9.0 CRITICAL (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
|Versions affected |all versions from `2.0-beta9` to `2.15.0` (excluding `2.3.1` and `2.12.3`)
|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later)
|===
@@ -190,18 +143,16 @@ Additional vulnerability details discovered independently by Ash Fox of Google,
[#CVE-2021-45046-references]
==== References
-- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046[CVE-2021-45046]
+- {cve-url-prefix}/CVE-2021-45046[CVE-2021-45046]
- https://issues.apache.org/jira/browse/LOG4J2-3221[LOG4J2-3221]
[#CVE-2021-44228]
-=== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228[CVE-2021-44228]
+=== {cve-url-prefix}/CVE-2021-44228[CVE-2021-44228]
[cols="1h,5"]
|===
|Summary |JNDI lookup can be exploited to execute arbitrary code loaded from an LDAP server
-|Type |Remote Code Execution
-|Severity |Critical
-|Base CVSS score |10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
+|CVSS 3.x Score & Vector |10.0 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
|Versions affected |all versions from `2.0-beta9` to `2.14.1` (excluding `2.3.1` and `2.12.3`)
|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later)
|===
@@ -225,7 +176,7 @@ include::_log4j1-eol.adoc[]
Log4j 1 does not have Lookups, so the risk is lower.
Applications using Log4j 1 are only vulnerable to this attack when they use JNDI in their configuration.
-A separate CVE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104[CVE-2021-4104]) has been filed for this vulnerability.
+A separate CVE ({cve-url-prefix}/CVE-2021-4104[CVE-2021-4104]) has been filed for this vulnerability.
To mitigate, audit your logging configuration to ensure it has no `JMSAppender` configured.
Log4j 1 configurations without `JMSAppender` are not impacted by this vulnerability.
@@ -242,18 +193,17 @@ This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
[#CVE-2021-44228-references]
==== References
-- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228[CVE-2021-44228]
+- {cve-url-prefix}/CVE-2021-44228[CVE-2021-44228]
- https://issues.apache.org/jira/browse/LOG4J2-3198[LOG4J2-3198]
- https://issues.apache.org/jira/browse/LOG4J2-3201[LOG4J2-3201]
[#CVE-2020-9488]
-=== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488[CVE-2020-9488]
+=== {cve-url-prefix}/CVE-2020-9488[CVE-2020-9488]
[cols="1h,5"]
|===
|Summary |Improper validation of certificate with host mismatch in SMTP appender
-|Severity |Low
-|Base CVSS score |3.7 (Low) CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
+|CVSS 3.x Score & Vector |3.7 LOW (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N)
|Versions affected |all versions from `2.0-beta1` to `2.13.1` (excluding `2.3.1` and `2.12.3`)
|Versions fixed |`2.12.3` (Java 7) and `2.13.2` (Java 8)
|===
@@ -285,18 +235,16 @@ This issue was discovered by Peter Stöckli.
[#CVE-2020-9488-references]
==== References
-- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488[CVE-2020-9488]
+- {cve-url-prefix}/CVE-2020-9488[CVE-2020-9488]
- https://issues.apache.org/jira/browse/LOG4J2-2819[LOG4J2-2819]
[#CVE-2017-5645]
-=== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645[CVE-2017-5645]
+=== {cve-url-prefix}/CVE-2017-5645[CVE-2017-5645]
[cols="1h,5"]
|===
|Summary |TCP/UDP socket servers can be exploited to execute arbitrary code
-|Type |Remote Code Execution
-|Severity |Moderate
-|Base CVSS score |7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
+|CVSS 3.x Score & Vector |9.8 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
|Versions affected |all versions from `2.0-alpha1` to `2.8.1`
|Versions fixed |`2.8.2` (Java 7)
|===
@@ -309,7 +257,7 @@ When using the TCP socket server or UDP socket server to receive serialized log
[#CVE-2017-5645-mitigation]
==== Mitigation
-Java 7 and above users should migrate to version 2.8.2 or avoid using the socket server classes.
+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 https://github.com/apache/logging-log4j2/commit/5dcc192[the security fix commit] from `2.8.2`.
[#CVE-2017-5645-credits]
@@ -320,6 +268,6 @@ This issue was discovered by Marcio Almeida de Macedo of Red Team at Telstra.
[#CVE-2017-5645-references]
==== References
-- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645[CVE-2017-5645]
+- {cve-url-prefix}/CVE-2017-5645[CVE-2017-5645]
- https://issues.apache.org/jira/browse/LOG4J2-1863[LOG4J2-1863]
- https://github.com/apache/logging-log4j2/commit/5dcc192[Security fix commit]
(logging-log4j2) 03/04: Add sub-entries to the `Security` menu entry (#1707)
Posted by vy...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
vy pushed a commit to branch security-page
in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
commit 1167a2a7dfe40f97ff595f19e6ca6d6e2fdf2108
Author: Volkan Yazıcı <vo...@yazi.ci>
AuthorDate: Mon Nov 6 20:19:52 2023 +0100
Add sub-entries to the `Security` menu entry (#1707)
---
src/site/site.xml | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/site/site.xml b/src/site/site.xml
index 786061835a..98dc4bdf4f 100644
--- a/src/site/site.xml
+++ b/src/site/site.xml
@@ -73,7 +73,6 @@
<item name="Getting support" href="/security.html#support" />
<item name="Reporting vulnerabilities" href="/security.html#reporting" />
<item name="Vulnerability handling policy" href="/security.html#policy" />
- <item name="Impact levels" href="/security.html#Security_Impact_Levels" />
<item name="Known Vulnerabilities" href="/security.html#vulnerabilities" />
</item>
</menu>