Upgrade to SnakeYAML 1.32

[snicoll]

No description provided.

[asomov]

I hope it is fully backwards compatible

[kvmw]

@asomov is this version (1.32) fixes the backward compatibility issue, regarding dates, which was mentioned in #32221 ?

I didn't find it in release notes.

[asomov]

@kvmw no it did not. It may bring even more confusion. But it is possible (especially because the corresponding CVE is considered a false positive)

[OrangeDog]

CVE-2022-38752 is still reported for 1.32, which is argued to be a false positive, but it is unclear whether the vulnerability has actually been fixed: https://bitbucket.org/snakeyaml/snakeyaml/issues/531/stackoverflow-oss-fuzz-47081#comment-64117937

In any case, as long as you don't allow user-provided YAML input (which in a standard Boot app depends how you're deploying your config) you can safely ignore this CVE.

[bclozel]

That is rather strange. The GitHub advisory states that this is fixed in 1.32, but the CVE assigned by Google doesn't mention any fix version, so NVD didn't not restrict the version in the known affected software configurations. Hopefully this will be fixed soon by NVD.

[bclozel]

It looks like the CVE entry is far from being fixed, see discussion in github/advisory-database#667.

[chadlwilson]

I think there is a bit of debate about whether it's a real 'vulnerability' in the first place (rather than risk implicit in using a YAML parser on arbitrary input), however let's put that aside for now. The CVE was seemingly (automatically?) raised on the basis of a single failing OSS Fuzz test yaml case, and that specific case now yields a SnakeYAML exception (about use of recursive keys, under default configuration) rather than the stack overflow which OSS Fuzz considers a denial of service. That OSS Fuzz issue is now considered resolved by their automated testing, so I think it seems reasonable to deem it 'fixed' from a CVE perspective which is the argument I've put forward to the NIST NVD. Whether a JVM-caught stack overflow is actually a denial of service seems a subject of reasonable debate, but maybe not so relevant to reducing the noise here.

It remains an open concern for users to continue using SnakeYAML to parse completely untrusted arbitrary input, and how far something like SnakeYAML should go to protect users/downstream libs from themselves (especially when in conflict with YAML specs), but that seems yet another different debate.

[chadlwilson]

NVD is updated now after my submission yesterday: https://nvd.nist.gov/vuln/detail/CVE-2022-38752 I believe only OSSIndex is marking some of these more recent vulns incorrectly right now.

[OrangeDog]

Unless I'm mistaken Boot 2.7.6 is still using SnakeYAML 1.30.
Shouldn't this have been included?

[bclozel]

@OrangeDog no we didn't upgrade on purpose, see #32221

[OrangeDog]

@bclozel where in there exactly? #32221 (comment) implies you were going to update to >=1.31

[snicoll]

@OrangeDog I would expect you'd be acquainted with our third party upgrade policy by now. That comment is about being compatible at runtime, not upgrading to a new feature release of a dependency in a maintenance release of Spring Boot.

[OrangeDog]

Clearly it's SnakeYAML's versioning policy I'm not familiar with. I thought 1.31 and 1.32 were bugfix releases.

[asomov]

@OrangeDog there was no bug to fix in SnakeYAML - there was a false positive which becomes silent after minor code modification