The Logging Services Security Team takes security seriously. This allows our users to place their trust in Log4j for protecting their mission-critical data. On this page, we will help you find guidance on security-related issues and access to known vulnerabilities.
|
Warning
|
Log4j 1 has 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 upgrade to Log4j 2 to obtain security fixes. |
Getting support
If you need help on building or configuring Logging Services projects or other help on following the instructions to mitigate the known vulnerabilities listed here, please use our user support channels.
|
Tip
|
If you need to apply a source code patch, use the building instructions for the project version that you are using.
These instructions can be found in |
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 the Logging Services Security Team.
|
Important
|
We urge you to carefully read the threat model detailed in following sections before submitting a report. It guides users on certain safety instructions while using Logging Services software and elaborates on what counts as an unexpected behaviour that has a security impact. |
Common threat model
All the logging frameworks maintained by Apache Logging Services (Log4cxx, Log4j and Log4net) face similar challenges from malicious actors. The following sections outline the most common threats to logging frameworks and clarify the assumptions regarding the origin and trustworthiness of various data sources. Vulnerability reports that do not adhere to these assumptions will not be accepted and are not eligible for the YesWeHack Bug Bounty Program.
User types
Apache Logging Services distinguishes two kinds of users:
- Trusted Users
-
Application developers and administrators are considered trusted users. They have unrestricted access to all the features of the logging framework and the environment it is deployed to.
- Untrusted Users
-
All the other users are considered untrusted.
Data sources
Logging systems read data from multiple sources that are controlled by both trusted and untrusted users:
- Trusted Sources
-
-
Log4cxx, Log4j, and Log4net trust environment variables, configuration properties, and configuration files. To maintain security, the following responsibilities fall on the deployer:
-
Ensure that untrusted parties do not have write access to these resources.
-
Ensure these resources are transmitted only over confidential channels (e.g., HTTPS, secure file systems).
-
Be aware that non-confidential channels such as HTTP or JMX are disabled by default to prevent accidental exposure.
-
If configuration files use interpolation features (e.g., (Log4j Lookups)), ensure that only trusted data sources are used.
-
Pay special attention to values stored in the context map (see Thread Context in Log4j). Although the context map is only accessible by developers, it has been known to include user-provided data, such as HTTP headers, which can introduce risks.
-
-
The logging frameworks trust that the objects passed to the log statements can be safely converted to strings:
-
These frameworks should not be used to log deserialized data from untrusted sources. See the related OWASP guide for details.
-
-
If parameterized logging is used, the format string is trusted:
-
Programmers should use compile-time constants as format strings to prevent attackers from tampering messages. See Don’t use string concatenation for an example.
-
-
- Untrusted Sources
-
-
Log4cxx, Log4j and Log4net do not trust log messages. No particular input validation for log messages is necessary.
-
They do not trust the string representation of log parameters.
-
The logging frameworks do not trust neither the keys nor the values in the thread context.
-
Threats
These are the most commonly encountered threats for users of Log4cxx, Log4j and Log4net:
- Log Injection (CWE-117)
-
Log injection is a common attack vector to hide malicious activity in an application. Regarding this threat:
-
Unstructured layouts such as Pattern Layout in Log4j do not protect users from log injection. These layouts are meant for human and not computer consumption.
-
Log4cxx, Log4j and Log4net must prevent log injection in structured layouts, such as XML, JSON and RFC 5424.
-
- Supply chain attacks (CWE-1357)
-
-
Apache Logging Services projects do check the quality of our dependencies.
-
Deprecated components such as the Cassandra, Kafka and CouchDB appenders are provided for backward compatibility purposes only. While we actively check for vulnerabilities in those components, they are de facto unmaintained, and we discourage their usage in production.
-
All Apache Logging Services are signed with one of the keys in the Logging Services PMC KEYS file. We do not support artifacts that do not have a valid signature, and we encourage users to always check the integrity of the downloaded components. Additional information on how to verify releases signatures is available on the Download page
-
- Information disclosure (CWE-200)
-
Since logging frameworks implement information disclosure by design:
-
It is up to the deployer to prevent unauthorized access to log files and to ensure that the appropriate log levels are configured.
-
It is up to the programmer to document which log levels and markers might contain sensitive data. Attention should be brought to the fact that libraries on which an application depends might have a different log level and marker convention.
-
Log masking techniques are out-of-scope for Log4cxx, Log4j, and Log4net. It is up to the developer to ensure that sensitive data is properly masked before it is passed to the logging implementation. For this purpose, third-party frameworks like Safe-Logging should be used.
-
- Log reliability (e.g. CVE-778)
-
Log4j is designed with reliability in mind:
-
By default, Log4j should deliver log events to the appropriate resource even during a reconfiguration event or will log an error.
-
While log events will be delivered to a resource, not all resources provide a confirmation mechanism. To ensure reliability along the entire logging pipeline, it is up to the deployer to use reliable transmission components: files, loopback network sockets or message-queue-based systems for example.
-
Log4j provides configuration options that discard log events if the load on the application is high. Using these options invalidates the reliability guarantees.
-
- Denial of service (CVE-779)
-
Since our logging frameworks are designed with reliability in mind:
-
Our frameworks go to great lengths to minimize performance overhead, minimize latency and maximizing throughput. Since a universal solution does not exist, many configuration options exist to adapt the performance characteristics to a specific application. See Performance for more information.
-
It is up to the deployer to ensure that the appenders can keep up with the logs written by using the appropriate appenders and configuring the appropriate level of logs.
-
It is up to the developer to ensure that log statements, which are not enabled, generate minimal overhead. See the Log4j API Best Practices, for example.
-
- Improper neutralization of Special Elements (CWE-138)
-
-
Log4cxx, Log4j, and Log4net do allow users to pass untrusted strings to log statements and thread context, except in the format string of parameterized logging, as mentioned above.
-
Vulnerability handling policy
The Logging Services Security Team follows the ASF Project Security guide for handling security vulnerabilities.
Reported security vulnerabilities are subject to voting (by means of lazy approval, preferably) in the private 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.
Vulnerability Disclosure Report (VDR)
Many Logging Services projects distribute CycloneDX Software Bill of Materials (SBOM) along with each deployed artifact. This is streamlined by Logging Parent for Maven-based projects.
Produced SBOMs contain BOM-links referring to a CycloneDX Vulnerability Disclosure Report (VDR) that Apache Logging Services uses for all projects it maintains. This VDR is accessible through the following URL: https://logging.apache.org/cyclonedx/vdr.xml
Known vulnerabilities
The Logging Services 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.
|
Note
|
We adhere to the Maven version range syntax while sharing versions of affected components.
We only extend this mathematical notation with set union operator (i.e., |
CVE-2021-44832
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 |
|
Versions affected |
|
Versions fixed |
|
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.
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.
References
CVE-2021-45105
Summary |
Infinite recursion in lookup evaluation |
|---|---|
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 |
|
Versions affected |
|
Versions fixed |
|
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.
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 than2.12.2(for Java 7), and2.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.
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.
References
CVE-2021-45046
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 |
|
Versions affected |
|
Versions fixed |
|
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.
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).
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).
References
CVE-2021-44228
Summary |
JNDI lookup can be exploited to execute arbitrary code loaded from an LDAP server |
|---|---|
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 |
|
Versions affected |
|
Versions fixed |
|
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.
Mitigation
Log4j 1 mitigation
|
Warning
|
Log4j 1 has 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 upgrade to Log4j 2 to obtain security fixes. |
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 (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.
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).
Credits
This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
References
CVE-2020-9488
Summary |
Improper validation of certificate with host mismatch in SMTP appender |
|---|---|
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 |
|
Versions affected |
|
Versions fixed |
|
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.
Mitigation
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.
Credits
This issue was discovered by Peter Stöckli.
References
CVE-2017-5645
Summary |
TCP/UDP socket servers can be exploited to execute arbitrary code |
|---|---|
CVSS 2.0 Score & Vector |
7.5 HIGH (AV:N/AC:L/Au:N/C:P/I:P/A:P) |
Components affected |
|
Versions affected |
|
Versions fixed |
|
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 from 2.8.2.
Credits
This issue was discovered by Marcio Almeida de Macedo of Red Team at Telstra.