[Bug]: Testcontainers uses outdated versions of Snakeyaml & Jackson, which have critical vulnerabilities, flagging testcontainers on security scanning tools

[ZachChuba]

Module

Core

Testcontainers version

1.20.1

Using the latest Testcontainers version?

Yes

Host OS

MacOS

Host Arch

ARM

Docker version

Client:
 Version:           26.1.4
 API version:       1.45
 Go version:        go1.21.11
 Git commit:        5650f9b
 Built:             Wed Jun  5 11:26:02 2024
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

What happened?

The testcontainers core shades snakeyaml 1.33 into the jar. Snakeyaml 1.33 is vulnerable to CVE-2022-1471. Even though the code does not appear vulnerable to this issue because it uses SafeConstructor, enterprises may blacklist testcontainers for the mere presence of snakeyaml 1.33. Please consider upgrading to snakeyaml 2.0 or higher.

Relevant log output

No response

Additional Information

https://nvd.nist.gov/vuln/detail/CVE-2022-1471

[mranjit]

I can see that the latest versions of snakeyaml do not have any vulnerabilities(https://mvnrepository.com/artifact/org.yaml/snakeyaml). Is upgrading to the latest version the only expectation? Then, I can create a pull request to upgrade it.

[ZachChuba]

Yes version 2.0 and above remediate it, upgrading to 2.2 would work

[eddumelendez]

Please, do not open a PR for this. We should take into account when update a dependency to a major version when doing patch and minor releases.

[PiotrSierkin-Ki]

Any updates on the status of this vulnerability? It is causing some concerns for us.

cc @eddumelendez

[Orbifoldt]

Also for us, Nexus IQ/Sonatype is blocking this

[gquintana]

CVE-2022-1471 SnakeYaml's Constructor() class does not restrict types which can be instantiated during deserialization. Deserializing yaml content provided by an attacker can lead to remote code execution. We recommend using SnakeYaml's SafeConsturctor when parsing untrusted content to restrict deserialization. We recommend upgrading to version 2.0 and beyond.
testcontainers-1.20.5.jar: org/testcontainers/shaded/org/yaml/snakeyaml/Yaml.class(, 2.0)

[asomov]

This is yet another false positive. The issue is very explicit about the untrusted source. Testcontainers use YAML as configuration from the classpath (not downloading it from some external URL without any control for the YAML provider).
Important: the CVE is correct, it warns and explains the context, but the tool which creates the false positive should be amended to radically improve the quality and stop sending false information blocking the developers.
Since the code uses SafeConstructor, there is no issue at all. So it is double false positive.
By the way, I can help to migrate to version 2 of SnakeYAML. The API is not backward compatible with version 1

Disclosure: in version 2, SnakeYAML's Constructor() class ALSO does not resctrict instantiation of arbitrary classes, but the tooling does not complain :-/

[asomov]

I have started the migration, but the tests in the main branch failed:

* What went wrong:
Execution failed for task ':activemq:spotlessJava'.

I do not want to make a PR without all the tests green. Can you please help me?

[ZachChuba]

Don't forget the other false positive -- test containers is only properly used in testing, so even if it were exploitable it would have trivial impact. Unfortunately, though, tools like sonatype only have the intelligence to assess presence of a vulnerable version, not if it is exploitable, or even used in the code. It's doubly annoying when a large enterprise has risk managers who have 0 care about exploitability and just want green charts, but have the power to block releases or even the dependency existing in the company's ecosystem because the chart isn't green. However, that's something many developers at enterprises deal with daily :(

[asomov]

@ZachChuba I wonder why the developers tolerate these low quality tooling which create a stream of false positives.
@gquintana since testcontainers already uses SafeConstructor, why should the project migrate? What is the added value? (except to satisfy the false positive generators)

[gquintana]

@asomov I truly understand your point.

Sadly, being considered as dangerous, nearly all testcontainers releases are considered as "security critical" and quarantined by Nexus dependency proxy. As a result, we can not use it at all, except very old releases.

I wonder whether having a testcontainer artefact without any dependency shaded in it (No Jackson, no SnakeYaml) could be a workaround. In our case most SnakeYaml releases are considered as "security critical" but very few are quarantined (don't ask me why). Same for Jackson, some releases are marked as "security critical" but none of them is quarantined. In the end the best solution could be to have a "slim" testcontainers Jar and let users manage their dependency hell by their own.