datadog-agent: Latest agent version does not mitigate Log4j vulnerability

According to Datadog’s official announcement, released versions 6.32.2 and 7.32.2 of the Agent that initializes the JVM for our JMX monitoring client with the following flag: -Dlog4j2.formatMsgNoLookups=True

A new CVE has been released since: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 18
Comments: 18 (7 by maintainers)

Most upvoted comments

We are currently working on releasing versions 6.32.3 and 7.32.3 of the Agent that include a patched version of the log4j library. We’ll update this issue when the release is available.

+16

olivielpeau on Dec 15, 2021

We have released 7.32.3 and 6.32.3 (https://github.com/DataDog/datadog-agent/releases/tag/7.32.3). These Agent versions include log4j 2.12.2, which fixes both CVE-2021-44228 and CVE-2021-45046, as documented on the log4j security page.

Please refer to https://www.datadoghq.com/log4j-vulnerability/ for further information, thanks!

olivielpeau on Dec 15, 2021

We are waiting for 7.32.3 and 6.32.3 https://github.com/DataDog/datadog-agent/pull/10240 and https://github.com/DataDog/datadog-agent/pull/10241

szibis on Dec 15, 2021

Datadog agent is downloading jmxfetch.jar file using jmxfetch.rb script with versions specified in release.json. It seems like jmxfetch version uses log4j version v2.12.2 even in the latest release. IMO, until jmxfetch is updated with log4j v2.16 and Datadog agent uses it, this issue won’t be addressed.

Is there any ETA on getting this fixed in jmxfetch and datadog-agent image with jmx?

knowshan on Dec 15, 2021

Hey @JorgenG, https://www.datadoghq.com/log4j-vulnerability/ has already been updated with the infromation about that CVE:

Versions 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.

With that said, we have just released agent versions 7.32.4 and 6.32.4 that completely remove log4j as a dependency from jmxfetch to mitigate any further concerns.

sgnn7 on Dec 22, 2021

@nwaldropEXR To be clear, our official chef cookbook is not affected by these vulnerabilities. The agent versions that it installs can be affected depending on the agent versions you’ve configured the cookbook to install. You can pin the version of the Agent that the cookbook installs with the ["datadog"]["agent_version"] attribute. You’ll find more details in the cookbook’s README

Please reach out to our support team if you have further questions about the chef cookbook, thanks!

olivielpeau on Dec 16, 2021

I check that and agent 7.32.2 was installed on 11.Dec using 0.44.4 version of JMXFetch and changes for using Log4j 2.12.2 are made in 0.44.5 https://github.com/DataDog/jmxfetch/releases/tag/0.44.5 Anyone can confirm that Datadog-agent still has Log4j issue ??

szibis on Dec 15, 2021

It seems like jmxfetch version uses log4j version v2.12.2 even in the latest release. IMO, until jmxfetch is updated with log4j v2.16 and Datadog agent uses it, this issue won’t be addressed.

@knowshan / @sudosoul I can’t comment on the timelines but per the upstream page at https://logging.apache.org/log4j/2.x/, 2.12.2 is not vulnerable:

The Log4j team has been made aware of a security vulnerability, CVE-2021-45046, that has been addressed in Log4j 2.12.2 for Java 7 and 2.16.0 for Java 8 and up. … In version 2.12.2 Log4j disables access to JNDI by default. Usage of JNDI in configuration now need to be enabled explicitly. Calls to the JndiLookup will now return a constant string. Also, Log4j now limits the protocols by default to only java. The message lookups feature has been completely removed.

sgnn7 on Dec 15, 2021