Full Report
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) contain a vulnerability (CVE-2021-44832) that could allow an attacker with permission to modify the logging configuration file to execute arbitrary code, when the JDBC Appender is used [1]. This advisory informs about the impact of CVE-2021-44832 to Siemens products and the corresponding remediation and mitigation measures. The vulnerability is different from other JNDI lookup vulnerabilities, the impact of which is documented in SSA-661247 [2]. Currently, no products vulnerable to CVE-2021-44832 have been identified. Siemens is investigating to determine which products are affected and is continuously updating this advisory as more information becomes available. See section Additional Information for more details regarding the investigation status. [1] https://logging.apache.org/log4j/2.x/security.html [2] https://cert-portal.siemens.com/productcert/pdf/ssa-661247.pdf
Analysis Summary
# Vulnerability: Apache Log4j2 JNDI RCE via JDBC Appender
## CVE Details
- **CVE ID:** CVE-2021-44832
- **CVSS Score:** 6.6 (Medium)
- **CWE:** CWE-20 (Improper Input Validation) / CWE-917 (Expression Language Injection)
## Affected Systems
- **Products:** Apache Log4j2; Siemens products (Investigation ongoing).
- **Versions:** 2.0-beta7 through 2.17.0 (Excluding 2.3.2 and 2.12.4).
- **Configurations:** Systems where the **JDBC Appender** is utilized and an attacker has the permissions required to modify the logging configuration file (e.g., `log4j2.xml`).
## Vulnerability Description
This vulnerability stems from a lack of controls over JNDI lookups within the JDBC Appender configuration. If an attacker can modify the Log4j2 configuration file, they can configure a JDBC Appender to use a data source via a JNDI URI. When the logging system initializes or reloads this configuration, it can be forced to fetch and execute a malicious payload from a remote server via JNDI, leading to Arbitrary Code Execution (ACE). Unlike Log4Shell (CVE-2021-44228), this flaw is not triggered by logged data but by the **configuration** itself.
## Exploitation
- **Status:** PoC available; not widely exploited in the wild compared to previous Log4j vulnerabilities.
- **Complexity:** High (Requires existing write-access to configuration files).
- **Attack Vector:** Local (Requires the ability to modify local or remote configuration files accessed by the application).
## Impact
- **Confidentiality:** High
- **Integrity:** High
- **Availability:** High
## Remediation
### Patches
Update to the following versions which restrict JNDI data sources:
- **Log4j 2.3.2** (for Java 6)
- **Log4j 2.12.4** (for Java 7)
- **Log4j 2.17.1** (for Java 8 and later)
### Workarounds
- Limit file system permissions to ensure that only authorized users/processes can modify the Log4j configuration files.
- Remove the `JndiLookup.class` from the classpath if JNDI is not required.
## Detection
- **Indicators of Compromise:** Unusual outbound JNDI/LDAP/RMI connections originating from a server running Log4j2.
- **Detection methods:**
- Audit Log4j2 configuration files (`.xml`, `.json`, `.yaml`, `.properties`) for the presence of `JDBC` appenders utilizing JNDI data sources.
- Software Composition Analysis (SCA) tools to identify vulnerable library versions in the stack.
## References
- Apache Security Advisory: hxxps[://]logging[.]apache[.]org/log4j/2[.]x/security[.]html
- Siemens Security Advisory: hxxps[://]cert-portal[.]siemens[.]com/productcert/pdf/ssa-661247[.]pdf
- NIST NVD Details: hxxps[://]nvd[.]nist[.]gov/vuln/detail/CVE-2021-44832