snakeyaml CVEs from OSS-Fuzz

[Dae]

Hi all,

I'm posting this in response to several of the comments surrounding the recently reported CVEs to provide our view of this. The CVEs I am referring to are:

• https://nvd.nist.gov/vuln/detail/CVE-2022-38749
• https://nvd.nist.gov/vuln/detail/CVE-2022-38750
• https://nvd.nist.gov/vuln/detail/CVE-2022-38751
• https://nvd.nist.gov/vuln/detail/CVE-2022-38752

Note: there appears to be a duplicate CVE that was not created by us with a higher CVSS score of 7.5 and a less descriptive message: https://nvd.nist.gov/vuln/detail/CVE-2022-25857.

Note 2: Regarding CVE-2022-38752's lack of a listed snakeyaml version, this was due to no fix currently implemented at the time of CVE creation. Since this should be delivered in snakeyaml 1.32, we will update the CVE to relfect this.

We (Code Intelligence) are working with Google to integrate more open source projects into OSS-Fuzz. The 4 above CVEs were created by Google based on findings that our fuzz target discovered. We consider these findings valid, not false positives since they trigger stack overflows in snakeyaml. We realize snakeyaml is not intended to be used with untrusted input and anyone feeding user input to snakeyaml should make every effort to sanitize it. However, there is no guarantee that snakeyaml is not / will not ever be used in this manner and these issues should be addressed by snakeyaml. The words "to parse untrusted YAML files" were included in the CVE description for this reason.

We see you have created a page on this repo related to this (https://bitbucket.org/snakeyaml/snakeyaml/wiki/CVE & NIST.md),,) but it might be helpful to make it more prominent and include the message / warning regarding expected usage of snakeyaml in the project README. Highlighting the configuration options to make snakeyaml more resilient to untrusted input may also be useful.

We will continue to create issues on this repo related to bugs discovered in snakeyaml via OSS-Fuzz so that these parsing issues, whether they could originate from trusted or untrusted input, can be fixed.

[Chad Wilson]

The CVEs have all been updated now, 38752 because I contacted NIST NVD directly to try and get the noise to stop :-) Unfortunately Sonatype OSSIndex still has no fix versions for CVE-2022-38751 and CVE-2022-38752 so if you have a way to contact them other than via Github ( https://github.com/OSSIndex/vulns/issues/327 and https://github.com/OSSIndex/vulns/issues/328) that might be useful to the community.

I guess this “issue” can be closed as seems more like an attempt at a discussion?

[Charlie Jin]

I also just got the notification on the new CVE https://nvd.nist.gov/vuln/detail/CVE-2022-41854 & https://security-tracker.debian.org/tracker/CVE-2022-41854. I assume this new CVE falls under the same scope as all the other ones mentioned above with a fix pending?

[Chad Wilson]

As the NVD data says, it was addressed in 1.32.

[Charlie Jin]

Hmm… I see, I didn’t read the NVD correctly then…. Thanks for the confirmation Chad.

[Sameer Kottapalli]

We are using version 1.33 but we still got this vulnerability. Can you confirm what is the issue here?

[Chad Wilson]

See #543 - unfortunately the NIST NVD entry is not linked to the issue in this tracker properly.

[Andrey Somov]

Sameer Kottapalli: what is the tool which reports the vulnerability ?

[Charlie Jin]

I checked and we are already using version 1.32 but still got this vulnerability. Our tool is Mend and it links to this in the vulnerability report: https://www.mend.io/vulnerability-database/CVE-2022-41854

[Andrey Somov]

@Charlie Jin how do you use SnakeYAML ? (do you simply use Spring Boot ?) Do you take unchecked input from untrusted users ?

[Charlie Jin]

@Andrey Somov We have a Java app that uses SnakeYaml 1.32 jar. We do not process input from untrusted users - we only parse Yaml file that is created internally and trusted.

[Andrey Somov]

@Charlie Jin why do not you want to create a bug report for Mend ? They report a false positive. They create lots of confusion and make my life difficult, because I have to waste tons of time to make this low quality tooling to shut up (without improving the quality of SnakeYAML!)

[Yash meet]

@Andrey Somov I am from @Sameer Kottapalli team. We are using Mend(Whitesource) tool. This is the vulnerability link from this tool https://www.mend.io/vulnerability-database/CVE-2022-41854.
Even mvnrepository https://mvnrepository.com/artifact/org.yaml/snakeyaml shows every version of SnakeYAML has vulnerability.

[Andrey Somov]

Please read the report: they say if and only if the data comes from untrusted source. Which is never the case (nobody presented a use case when the data comes from unknown and untrusted source)

https://bitbucket.org/snakeyaml/snakeyaml/wiki/CVE & NIST.md

Do not trust low quality tolling and their false positives !

[Chad Wilson]

As a general community member I agree with Andrey, you need to directly contact MVNRepository and Mend if you disagree with their data. I sorted out OSS Index and the NIST NVD for a number of these by contacting directly but can't cover every single random proprietary database of vulnerabilities.

[Marcel Stör]

Do not trust low quality tolling and their false positives !

@Andrey Somov well said - costs a lot of people an enormous amount of time. Maybe slap a big fat note onto the README, link to the Wiki and close this issue?

[Andrey Somov]

When one issue closes, another opens. I am sick and tied of it. I want to keep it open to give the context to those who still respects the conclusions from the low quality tooling.

‌

[Dmitry Popov]

The new https://nvd.nist.gov/vuln/detail/CVE-2022-1471 is critical, has to be urgently fixed.

[Andrey Somov]

• there is nothing to fix
• it is unrelated to this topic

‌

why not to search before you add a message ?

https://bitbucket.org/snakeyaml/snakeyaml/issues/563/cve-2022-1471-snakeyamls-constructor-class

‌

https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-2022-1471-vulnerability-in

‌

‌

‌