|
| 1 | +//// |
| 2 | + Licensed to the Apache Software Foundation (ASF) under one or more |
| 3 | + contributor license agreements. See the NOTICE file distributed with |
| 4 | + this work for additional information regarding copyright ownership. |
| 5 | + The ASF licenses this file to You under the Apache License, Version 2.0 |
| 6 | + (the "License"); you may not use this file except in compliance with |
| 7 | + the License. You may obtain a copy of the License at |
| 8 | + |
| 9 | + https://www.apache.org/licenses/LICENSE-2.0 |
| 10 | + |
| 11 | + Unless required by applicable law or agreed to in writing, software |
| 12 | + distributed under the License is distributed on an "AS IS" BASIS, |
| 13 | + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 14 | + See the License for the specific language governing permissions and |
| 15 | + limitations under the License. |
| 16 | +//// |
| 17 | +
|
| 18 | +:cve-url-prefix: https://nvd.nist.gov/vuln/detail |
| 19 | +
|
| 20 | += Security |
| 21 | +
|
| 22 | +The Apache Log4j Security Team takes security seriously. |
| 23 | +This allows our users to place their trust in Log4j for protecting their mission-critical data. |
| 24 | +In this page we will help you find guidance on security-related issues and access to known vulnerabilities. |
| 25 | +
|
| 26 | +include::_log4j1-eol.adoc[] |
| 27 | +
|
| 28 | +[#support] |
| 29 | +== Getting support |
| 30 | +
|
| 31 | +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]. |
| 32 | +
|
| 33 | +[TIP] |
| 34 | +==== |
| 35 | +If you need to apply a source code patch, use the building instructions for the Log4j version that you are using. |
| 36 | +These instructions can be found in `BUILDING.md` distributed with the sources. |
| 37 | +==== |
| 38 | +
|
| 39 | +[#reporting] |
| 40 | +== Reporting vulnerabilities |
| 41 | +
|
| 42 | +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:[email protected][the Log4j Security Team]. |
| 43 | +
|
| 44 | +[WARNING] |
| 45 | +==== |
| 46 | +The threat model that Log4j uses considers configuration files as safe input controlled by the programmer; **potential vulnerabilities that require the ability to modify a configuration are not considered vulnerabilities** as the required access to do so implies the attacker can execute arbitrary code. |
| 47 | +==== |
| 48 | +
|
| 49 | +[#policy] |
| 50 | +== Vulnerability handling policy |
| 51 | +
|
| 52 | +The Apache Log4j Security Team follows the https://www.apache.org/security/committers.html[ASF Project Security] guide for handling security vulnerabilities. |
| 53 | +
|
| 54 | +Reported security vulnerabilities are subject to voting (by means of https://logging.apache.org/guidelines.html[_lazy approval_], preferably) in the private mailto:[email protected][security mailing list] before creating a CVE and populating its associated content. |
| 55 | +This procedure involves only the creation of CVEs and blocks neither (vulnerability) fixes, nor releases. |
| 56 | +
|
| 57 | +[#vdr] |
| 58 | +== Vulnerability Disclosure Report (VDR) |
| 59 | +
|
| 60 | +Starting with version `2.22.0`, Log4j distributes https://cyclonedx.org/capabilities/vdr[CycloneDX Software Bill of Materials (SBOM)] along with each deployed artifact. |
| 61 | +Produced SBOMs contain BOM-links referring to a https://cyclonedx.org/capabilities/vdr[CycloneDX Vulnerability Disclosure Report (VDR)] that Apache Logging Services uses for all projects it maintains. |
| 62 | +All this is streamlined by `logging-parent`, see https://logging.apache.org/logging-parent/latest/#cyclonedx-sbom[its website] for details. |
| 63 | +
|
| 64 | +[#vulnerabilities] |
| 65 | +== Known vulnerabilities |
| 66 | +
|
| 67 | +The Log4j Security Team believes that accuracy, completeness and availability of security information is essential for our users. |
| 68 | +We choose to pool all information on this one page, allowing easy searching for security vulnerabilities over a range of criteria. |
| 69 | +
|
| 70 | +[NOTE] |
| 71 | +==== |
| 72 | +We adhere to https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html[the Maven version range syntax] while sharing versions of affected components. |
| 73 | +We only extend this mathematical notation with set union operator (i.e., `∪`) to denote union of multiple ranges. |
| 74 | +==== |
| 75 | +
|
| 76 | +[#CVE-2021-44832] |
| 77 | +=== {cve-url-prefix}/CVE-2021-44832[CVE-2021-44832] |
| 78 | +
|
| 79 | +[cols="1h,5"] |
| 80 | +|=== |
| 81 | +|Summary |JDBC appender is vulnerable to remote code execution in certain configurations |
| 82 | +|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) |
| 83 | +|Components affected |`log4j-core` |
| 84 | +|Versions affected |`[2.0-beta7, 2.3.2) ∪ [2.4, 2.12.4) ∪ [2.13.0, 2.17.1)` |
| 85 | +|Versions fixed |`2.3.2` (for Java 6), `2.12.4` (for Java 7), or `2.17.1` (for Java 8 and later) |
| 86 | +|=== |
| 87 | +
|
| 88 | +[#CVE-2021-44832-description] |
| 89 | +==== Description |
| 90 | +
|
| 91 | +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. |
| 92 | +This issue is fixed by limiting JNDI data source names to the `java` protocol. |
| 93 | +
|
| 94 | +[#CVE-2021-44832-mitigation] |
| 95 | +==== Mitigation |
| 96 | +
|
| 97 | +Upgrade to `2.3.2` (for Java 6), `2.12.4` (for Java 7), or `2.17.1` (for Java 8 and later). |
| 98 | +
|
| 99 | +In prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than `java`. |
| 100 | +
|
| 101 | +[#CVE-2021-44832-references] |
| 102 | +==== References |
| 103 | +- {cve-url-prefix}/CVE-2021-44832[CVE-2021-44832] |
| 104 | +
|
| 105 | +[#CVE-2021-45105] |
| 106 | +=== {cve-url-prefix}/CVE-2021-45105[CVE-2021-45105] |
| 107 | +
|
| 108 | +[cols="1h,5"] |
| 109 | +|=== |
| 110 | +|Summary |Infinite recursion in lookup evaluation |
| 111 | +|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) |
| 112 | +|Components affected |`log4j-core` |
| 113 | +|Versions affected |`[2.0-alpha1, 2.3.1) ∪ [2.4, 2.12.3) ∪ [2.13.0, 2.17.0)` |
| 114 | +|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), and `2.17.0` (for Java 8 and later) |
| 115 | +|=== |
| 116 | +
|
| 117 | +[#CVE-2021-45105-description] |
| 118 | +==== Description |
| 119 | +
|
| 120 | +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. |
| 121 | +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. |
| 122 | +This is also known as a _DoS (Denial-of-Service)_ attack. |
| 123 | +
|
| 124 | +[#CVE-2021-45105-mitigation] |
| 125 | +==== Mitigation |
| 126 | +
|
| 127 | +Upgrade to `2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later). |
| 128 | +
|
| 129 | +Alternatively, this infinite recursion issue can be mitigated in configuration: |
| 130 | +
|
| 131 | +* In PatternLayout in the logging configuration, replace Context Lookups like `${ctx:loginId}` or `$${ctx:loginId}` with Thread Context Map patterns (`%X`, `%mdc`, or `%MDC`). |
| 132 | +* Otherwise, in the configuration, remove references to Context Lookups like `${ctx:loginId}` or `$${ctx:loginId}` where they originate |
| 133 | +from sources external to the application such as HTTP headers or user input. |
| 134 | +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. |
| 135 | +
|
| 136 | +Note that only the `log4j-core` JAR file is impacted by this vulnerability. |
| 137 | +Applications using only the `log4j-api` JAR file without the `log4j-core` JAR file are not impacted by this vulnerability. |
| 138 | +
|
| 139 | +[#CVE-2021-45105-credits] |
| 140 | +==== Credits |
| 141 | +
|
| 142 | +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. |
| 143 | +
|
| 144 | +[#CVE-2021-45105-references] |
| 145 | +==== References |
| 146 | +
|
| 147 | +- {cve-url-prefix}/CVE-2021-45105[CVE-2021-45105] |
| 148 | +- https://issues.apache.org/jira/browse/LOG4J2-3230[LOG4J2-3230] |
| 149 | +
|
| 150 | +[#CVE-2021-45046] |
| 151 | +=== {cve-url-prefix}/CVE-2021-45046[CVE-2021-45046] |
| 152 | +
|
| 153 | +[cols="1h,5"] |
| 154 | +|=== |
| 155 | +|Summary |Thread Context Lookup is vulnerable to remote code execution in certain configurations |
| 156 | +|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) |
| 157 | +|Components affected |`log4j-core` |
| 158 | +|Versions affected |`[2.0-beta9, 2.3.1) ∪ [2.4, 2.12.3) ∪ [2.13.0, 2.17.0)` |
| 159 | +|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), and `2.17.0` (for Java 8 and later) |
| 160 | +|=== |
| 161 | +
|
| 162 | +[#CVE-2021-45046-description] |
| 163 | +==== Description |
| 164 | +
|
| 165 | +It was found that the fix to address <<CVE-2021-44228>> in Log4j `2.15.0` was incomplete in certain non-default configurations. |
| 166 | +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. |
| 167 | +Remote code execution has been demonstrated on macOS, Fedora, Arch Linux, and Alpine Linux. |
| 168 | +
|
| 169 | +Note that this vulnerability is not limited to just the JNDI lookup. |
| 170 | +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. |
| 171 | +
|
| 172 | +Note that only the `log4j-core` JAR file is impacted by this vulnerability. |
| 173 | +Applications using only the `log4j-api` JAR file without the `log4j-core` JAR file are not impacted by this vulnerability. |
| 174 | +
|
| 175 | +[#CVE-2021-45046-mitigation] |
| 176 | +==== Mitigation |
| 177 | +
|
| 178 | +Upgrade to Log4j `2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later). |
| 179 | +
|
| 180 | +[#CVE-2021-45046-credits] |
| 181 | +==== Credits |
| 182 | +
|
| 183 | +This issue was discovered by Kai Mindermann of iC Consult and separately by 4ra1n. |
| 184 | +
|
| 185 | +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). |
| 186 | +
|
| 187 | +[#CVE-2021-45046-references] |
| 188 | +==== References |
| 189 | +
|
| 190 | +- {cve-url-prefix}/CVE-2021-45046[CVE-2021-45046] |
| 191 | +- https://issues.apache.org/jira/browse/LOG4J2-3221[LOG4J2-3221] |
| 192 | +
|
| 193 | +[#CVE-2021-44228] |
| 194 | +=== {cve-url-prefix}/CVE-2021-44228[CVE-2021-44228] |
| 195 | +
|
| 196 | +[cols="1h,5"] |
| 197 | +|=== |
| 198 | +|Summary |JNDI lookup can be exploited to execute arbitrary code loaded from an LDAP server |
| 199 | +|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) |
| 200 | +|Components affected |`log4j-core` |
| 201 | +|Versions affected |`[2.0-beta9, 2.3.1) ∪ [2.4, 2.12.3) ∪ [2.13.0, 2.17.0)` |
| 202 | +|Versions fixed |`2.3.1` (for Java 6), `2.12.3` (for Java 7), and `2.17.0` (for Java 8 and later) |
| 203 | +|=== |
| 204 | +
|
| 205 | +[#CVE-2021-44228-description] |
| 206 | +==== Description |
| 207 | +
|
| 208 | +In Log4j, the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. |
| 209 | +An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers. |
| 210 | +
|
| 211 | +Note that only the `log4j-core` JAR file is impacted by this vulnerability. |
| 212 | +Applications using only the `log4j-api` JAR file without the `log4j-core` JAR file are not impacted by this vulnerability. |
| 213 | +
|
| 214 | +[#CVE-2021-44228-mitigation] |
| 215 | +==== Mitigation |
| 216 | +
|
| 217 | +[#CVE-2021-44228-mitigation-log4j1] |
| 218 | +===== Log4j 1 mitigation |
| 219 | +
|
| 220 | +include::_log4j1-eol.adoc[] |
| 221 | +
|
| 222 | +Log4j 1 does not have Lookups, so the risk is lower. |
| 223 | +Applications using Log4j 1 are only vulnerable to this attack when they use JNDI in their configuration. |
| 224 | +A separate CVE ({cve-url-prefix}/CVE-2021-4104[CVE-2021-4104]) has been filed for this vulnerability. |
| 225 | +To mitigate, audit your logging configuration to ensure it has no `JMSAppender` configured. |
| 226 | +Log4j 1 configurations without `JMSAppender` are not impacted by this vulnerability. |
| 227 | +
|
| 228 | +[#CVE-2021-44228-mitigation-log4j2] |
| 229 | +===== Log4j 2 mitigation |
| 230 | +
|
| 231 | +Upgrade to Log4j `2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later). |
| 232 | +
|
| 233 | +[#CVE-2021-44228-credits] |
| 234 | +==== Credits |
| 235 | +
|
| 236 | +This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team. |
| 237 | +
|
| 238 | +[#CVE-2021-44228-references] |
| 239 | +==== References |
| 240 | +
|
| 241 | +- {cve-url-prefix}/CVE-2021-44228[CVE-2021-44228] |
| 242 | +- https://issues.apache.org/jira/browse/LOG4J2-3198[LOG4J2-3198] |
| 243 | +- https://issues.apache.org/jira/browse/LOG4J2-3201[LOG4J2-3201] |
| 244 | +
|
| 245 | +[#CVE-2020-9488] |
| 246 | +=== {cve-url-prefix}/CVE-2020-9488[CVE-2020-9488] |
| 247 | +
|
| 248 | +[cols="1h,5"] |
| 249 | +|=== |
| 250 | +|Summary |Improper validation of certificate with host mismatch in SMTP appender |
| 251 | +|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) |
| 252 | +|Components affected |`log4j-core` |
| 253 | +|Versions affected |`[2.0-beta1, 2.12.3) ∪ [2.13.1, 2.13.2)` |
| 254 | +|Versions fixed |`2.12.3` (Java 7) and `2.13.2` (Java 8 and later) |
| 255 | +|=== |
| 256 | +
|
| 257 | +[#CVE-2020-9488-description] |
| 258 | +==== Description |
| 259 | +
|
| 260 | +Improper validation of certificate with host mismatch in SMTP appender. |
| 261 | +This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log |
| 262 | +messages sent through that appender. |
| 263 | +
|
| 264 | +The reported issue was caused by an error in `SslConfiguration`. |
| 265 | +Any element using `SslConfiguration` in the Log4j `Configuration` is also affected by this issue. |
| 266 | +This includes `HttpAppender`, `SocketAppender`, and `SyslogAppender`. |
| 267 | +Usages of `SslConfiguration` that are configured via system properties are not affected. |
| 268 | +
|
| 269 | +[#CVE-2020-9488-mitigation] |
| 270 | +==== Mitigation |
| 271 | +
|
| 272 | +Upgrade to `2.12.3` (Java 7) or `2.13.2` (Java 8 and later). |
| 273 | +
|
| 274 | +Alternatively, users can set the `mail.smtp.ssl.checkserveridentity` system property to `true` to enable SMTPS hostname verification for all SMTPS mail sessions. |
| 275 | +
|
| 276 | +[#CVE-2020-9488-credits] |
| 277 | +==== Credits |
| 278 | +
|
| 279 | +This issue was discovered by Peter Stöckli. |
| 280 | +
|
| 281 | +[#CVE-2020-9488-references] |
| 282 | +==== References |
| 283 | +
|
| 284 | +- {cve-url-prefix}/CVE-2020-9488[CVE-2020-9488] |
| 285 | +- https://issues.apache.org/jira/browse/LOG4J2-2819[LOG4J2-2819] |
| 286 | +
|
| 287 | +[#CVE-2017-5645] |
| 288 | +=== {cve-url-prefix}/CVE-2017-5645[CVE-2017-5645] |
| 289 | +
|
| 290 | +[cols="1h,5"] |
| 291 | +|=== |
| 292 | +|Summary |TCP/UDP socket servers can be exploited to execute arbitrary code |
| 293 | +|CVSS 2.0 Score & Vector |7.5 HIGH (AV:N/AC:L/Au:N/C:P/I:P/A:P) |
| 294 | +|Components affected |`log4j-core` |
| 295 | +|Versions affected |`[2.0-alpha1, 2.8.2)` |
| 296 | +|Versions fixed |`2.8.2` (Java 7) |
| 297 | +|=== |
| 298 | +
|
| 299 | +[#CVE-2017-5645-description] |
| 300 | +==== Description |
| 301 | +
|
| 302 | +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. |
| 303 | +
|
| 304 | +[#CVE-2017-5645-mitigation] |
| 305 | +==== Mitigation |
| 306 | +
|
| 307 | +Java 7 and above users should migrate to version `2.8.2` or avoid using the socket server classes. |
| 308 | +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`. |
| 309 | +
|
| 310 | +[#CVE-2017-5645-credits] |
| 311 | +==== Credits |
| 312 | +
|
| 313 | +This issue was discovered by Marcio Almeida de Macedo of Red Team at Telstra. |
| 314 | +
|
| 315 | +[#CVE-2017-5645-references] |
| 316 | +==== References |
| 317 | +
|
| 318 | +- {cve-url-prefix}/CVE-2017-5645[CVE-2017-5645] |
| 319 | +- https://issues.apache.org/jira/browse/LOG4J2-1863[LOG4J2-1863] |
| 320 | +- https://github.com/apache/logging-log4j2/commit/5dcc192[Security fix commit] |
0 commit comments