Update on our Response to the Log4j Vulnerability
December 12, 2021As you may be aware, the Apache Foundation recently announced that Log4j, a popular Java logging library, is vulnerable to remote code execution. MITRE has labeled the vulnerability as CVE-2021-44228 and assigned it the highest CVSS score (10.0). If exploited, this vulnerability can give an attacker full control of any impacted system. In addition, the Apache Foundation has disclosed two other vulnerabilities (CVE-2021-45046 and CVE-2021-45105) that could allow a denial of service attack against the impacted system.
Immediately following the announcement, our security and engineering teams began working to evaluate all of our products and internal services for any potential impact. We’d like to inform you of our findings and what steps we have taken to remediate any affected services.
Our security research team has published a more in-depth analysis of the Log4j vulnerability and provided ways Datadog security products can help detect any attacks of this vulnerability.
Please visit this page for the most up-to-date information. If you are a customer and want more information, please file a support ticket or contact your Datadog support or success team
Summary of impact for customers
Our information security and engineering teams have updated any services that use Log4j, whether directly or indirectly through third-party components. In addition, we have been continuously monitoring and have not detected any successful attacks against our infrastructure.
Please find below a list of relevant components, such as Agents or libraries, that you as a Datadog customer may be running in your own environments. We have included a summary of any potential impact of this exploit on each component and the remediation steps we have taken.
| Product | Versions | Impact | Remediation |
|---|
| Datadog Agent | 6.32.3 & 7.32.3 | - Our analysis of CVE-2021-45105 indicates that the JMXfetch client is not affected. The implementation has a hardcoded PatternLayout and does not use any context lookup. As a result, it does not rely on any configuration that an attacker can control to execute the exploit. | Released versions 7.32.4 and 6.32.4 which completely remove Log4j from the Datadog Agent and JMXfetch. |
| >= 6.17.0 - <= 6.32.2
>= 7.17.0 - <= 7.32.2 | - CVE-2021-44228 and CVE-2021-44228: Our JMX monitoring client — used by some of our Agent integrations to connect to your internal Java applications through JMX — includes Log4j. This monitoring is not turned on by default and customers have to explicitly enable it by enabling an integration that uses JMX, or by creating a custom JMX check.
- CVE-2021-44228 and CVE-2021-44228: Our analysis concluded that exploiting Log4j through JMX via a vulnerable Agent version already requires full control of the JMX endpoint. Out of an abundance of caution, we still recommend the upgrade of the Agent to 6.32.4 or 7.32.4.
- Our APM trace library does not ship with Log4j, even when our JMX fetch library is embedded. The APM trace library relies on the logging library that is included with the application that it is monitoring | Agent versions 6.32.3 and 7.32.3 use Log4j version 2.12.2. These versions fix CVE-2021-45046 and CVE-2021-44228. Agent versions 6.32.3 and 7.32.3 are not affected by CVE-2021-45105, but they may still trigger security scans because of the presence of Log4j version 2.12.2. Versions 7.32.4 and 6.32.4 should not trigger security scans for the presence of the Log4j.
Note: Customers who are running impacted versions of our Agent and cannot update to the version that mitigates the vulnerability can also utilize these mitigations. (See also these recommendations from Apache.) |
| datadog-lambda-java | <= 0.3.3
<= 1.4.0 | There is no direct impact to our library since we do not directly use Log4j. However, following AWS’s recommendation, we released a new version of our library that uses the latest version of amazon-lambda-java-log4j2 (1.4.0). | We have released versions 1.4.2 and 0.3.5 to meet the recommended solution proposed by AWS. |
| datadog-kafka-connect-logs | <= 1.0.3 | - After performing our analysis of CVE-2021-45105, we have decided to publish a new release of this plugin that completely removes the Log4j dependency. The plugin will rely on the logging library the Kafka connect runtime provides, please see Confluent’s advisory for more information.
- Our analysis concluded that this plugin will log contents of the messages consumed from the Kafka topics it is configured to read when errors occur. However, exploiting Log4j in this situation requires control of the messages being sent to the plugin. | We have released version 1.0.3 of the plugin that completely removes its dependency on Log4j. |
| All other supported products | All | No impact | NA |
References
We are providing the following links to provide more context regarding the vulnerability:
Changelog
- 2021-12-22: Updated page to reflect new release of the Datadog Agent that removes Log4j as a dependency for the JMXfetch client.
- 2021-12-18: Added our analysis of CVE-2021-45105, updated our Impact assessment for the Agent, and announced the new release of the datadog-kafka-connect-logs plugin.
- 2021-12-15: Added datadog-lambda-java and datadog-kafka-connect-logs, and information related to CVE-2021-45046.
- 2021-12-12: Updated communications to reflect any impact by product.
- 2021-12-10: Original communications sent out via PDF to customers who inquired, notifying them of the no impact as well as the upcoming version of Agent software.