[GHSA-c4r9-r8fh-9vj2] snakeYAML before 1.31 vulnerable to Denial of Service due to Out-of-bounds Write

[jensdietrich]

Updates

• Affected products
• Description

Comments
Several other components are also affected as a result of cloning or shading. Proof-of-Vulnerability projects with tests to verify the presence of the CVE can be found here: https://github.com/jensdietrich/xshady-release/ . Those projects were detected with a research tool our team has developed.

[taladrane]

👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the Keep label to hold stale off permanently, or do nothing. If you do nothing this pull request will be closed eventually by the stale bot. Please see CONTRIBUTING.md for more policy details.

[darakian]

Hey @jensdietrich, sorry for the delay. I took a look at your repo and I'm not sure how to interpret it. Can you elaborate on what the results are and how they were generated?

[jensdietrich]

Hi @darakian,

The proposed new entries are a result of a research project with collaborators from academia and industry (Oracle Labs). We were looking at how cloning and shading code leads to the propagation of vulnerabilities, and whether existing SCA tools and databases (NVD, GHSA) miss those. We run a custom clone detection on Maven artifacts, and confirmed the vulnerabilities through proof-of-vulnerability (POV) projects. The respective project for CVE-2022-38749 in org.yaml:snakeyaml can be found in https://github.com/jensdietrich/xshady/tree/main/CVE-2022-38749 – there is a single test that loads a vulnerable payload (CVE-2022-38749.yml) and checks that this results in a stack overflow error. I.e. if mvn test succeeds, the vulnerability is present. The test is based on the output of oss-fuzz .

The projects in https://github.com/jensdietrich/xshady-release/tree/main/CVE-2022-38749 are clones of the POV for the additional components reported in this PR. Those projects make the following modifications: (1) in pom.xml, the dependency to org.yaml:snakeyaml is replaced by a dependency to the respective component cloning or shading the original artifact. (2) if the clone used shading, import statements are updated to point to the shaded (relocated) package(s). To verify that those projects are vulnerable, please clone the repo, and run mvn test for each project.

Each project also contains a folder /scan-results containing the outputs of three SCA tools (snyk, grype, owasp dependency check and steady) at the time of commit. This was to demonstrate that (some/all) tools miss the respective vulnerability as they are not listed in the database. I.e. to avoid effective false positives. Btw, most tools pick up the CVE in the original project (the exception is steady, as its database hasn't been updated for 2022 CVEs).

There are a few more PRs for similar CVEs either already open, or in preparation. There are also a few more instances where we deemed the projects as critical, and reported to vendors / projects first before going public.

I hope this helps. A paper describing the approach is under submission atm but if you advise a way to contact you privately we can share this.

Cheers, Jens

[darakian]

We were looking at how cloning and shading code leads to the propagation of vulnerabilities

ie. copy+ pasting of code? Certainly our DB would not capture instances of copied code since we index on packages. Is your tool open such that I can validate your results?

through proof-of-vulnerability

I've not come across this term before. How do you define it?

if you advise a way to contact you privately we can share this.

When this becomes public we'll be happy to revisit this, but as it stands it seems like it's not possible to independently validate your claims. We aim to ensure that our advisories are independently verifiable, so private disclosure of the paper would run against that goal.

[jensdietrich]

Give me a few days to discuss this with collaborators (we are in different timezones, so this always takes a day or two). The tool is on GH but not public atm, re the paper -- there is a double-blind submission process but we can probably put this up on arxiv. Will discuss and come back to you soon.

[darakian]

Sounds good. 👍

[jensdietrich]

The approach used to detect this is described here:

https://u.pcloud.link/publink/show?code=XZGQhEVZOpW1a5DGoPF6S2nSq6Yrdjc1k8oX

(please don’t share the link widely as this is under double-blidn review atm)

We report additional packages affected by the same vulnerability because they are (or include) copies of the vulnerable package that GHSA already indexed. Any client application using these packages that we report is potentially vulnerable in the same way as if was using the already indexed vulnerable package.

This is not a static analysis, so it does not produce false positives. The POV are used for this purpose. We did not invent this term, it is for instance also used here:

https://github.com/tuhh-softsec/vul4j (related: Bui et al: "Vul4J: a dataset of reproducible Java vulnerabilities geared towards the study of program repair techniques." MSR’22).

and:

https://s2e.systems/docs/Tutorials/PoV/pov.html
Basically, POVs are proof-of-concept for exploits, the term is slightly more specific to vulnerabilities.

Our findings are already public, this is the purpose of https://github.com/jensdietrich/xshady-release .

[darakian]

Many thanks! Give me a bit to read through the paper, but also do you have an expected date for the double blind submission to be over? It would be nice to link to the paper or a summary of the paper on your repo as a reference assuming we accept these changes. Side note; we may need to reopen #2326. It got closed without changes in error.

[jensdietrich]

No problem. Author notification is 31 July 23. We will add a summary of the research to the repos as suggested.

[jensdietrich]

I have updated the README in https://github.com/jensdietrich/xshady-release/ with a high-level description of how our tool works and how we find those projects, as suggested. I hope this helps.

[darakian]

Sorry for the delayed reply. Read through the paper and spot checked a few of the dependencies to validate that snakeYaml does indeed show up and 👍
I look forward to the tool's source showing up as well 😉

Only question I have left in mind is how to reference the paper in the advisory. I suppose you don't want a reference to it until the peer review is over?

[jensdietrich]

Great ! I will discuss the paper reference with the team, please give me 1-2 days (different time zones .. ).

[darakian]

Sounds good.

please give me 1-2 days

No rush at all 👍

[jensdietrich]

the arxiv paper should come through next Monday, I will advise the URL as soon as we have it

[jensdietrich]

the paper is now publically available on arxiv:
article URL: https://arxiv.org/abs/2306.05534
direct link to PDF: https://arxiv.org/pdf/2306.05534

Please let us know whether there is anything else we can do. There are some open PRs (#2326 , #2327 , #2273), the process used to identify those was identical. Please also let us know whether you need more input for those. Finally, we do have results for a few more CVEs (results are all in https://github.com/jensdietrich/xshady-release/ ) -- should we create additional PRs for those as well ?

[darakian]

Cool. I've gone ahead and updated GHSA-c4r9-r8fh-9vj2. I had to put the edits in manually I think because of your pl.droidsonroids.yaml:snakeyaml entries. <= 1.18.2 contains 1.18-android in our version range logic. I'll get to the others as well but if all's well I'll close this one out 👍

should we create additional PRs for those as well ?

Yep. Feel free to make more, though if you plan to do this regularly we should probably talk about a more sustainable system 😃

[jensdietrich]

@darakian re: "Feel free to make more, though if you plan to do this regularly we should probably talk about a more sustainable system" -- we have more coming, starting with a batch of 12, the first one is #2823 by @wtwhite . Any suggestion how a more sustainable system could look like ?

[darakian]

@jensdietrich, I'm not sure I have a good answer for you 😞
I have around a week per month at the moment to review PRs in this repo and essentially the more complex the PR the less likely it is to get looked at :/

Edit: One thing that would help is if you could go the extra mile and get fix commits (if fixed) or source links for the packages