Add advisories for standard library soundness bugs

[Qwaz]

We recently re-discovered rust-lang/rust#60977 and rust-lang/rust#78498 in abi_stable crate. While investigating, we found a few more interesting bugs in the Rust issue tracker. I believe these bugs need advisories; I'll leave the list here so that someone else can look into them and file an advisory.

These are memory safety/soundness bugs in stable APIs.

• VecDeque: length 0 underflow and bogus values from pop_front(), triggered by a certain sequence of reserve(), push_back(), make_contiguous(), pop_front() rust-lang/rust#79808
• String::retain allows safely creating invalid (non-utf8) strings when abusing panic rust-lang/rust#78498

---

These are bugs in unstable APIs, so probably no advisory is needed. (But they are still quite interesting bugs!)

• Double drop in Vec::drain_filter rust-lang/rust#60977
• Soundness issue in Drop for SyncOnceCell rust-lang/rust#76367

[alex]

Should be possible to submit them here: https://github.com/RustSec/advisory-db/tree/master/rust/std

[Qwaz]

Adding one more to the list :)
rust-lang/rust#80335

[Qwaz]

Found one more old bug.
rust-lang/rust#25842

[Qwaz]

Heap buffer overflow in read_to_end_with_reservation() rust-lang/rust#80894

[Qwaz]

Update:

We contacted the Rust security team (security@rust-lang.org) about the process of requesting CVEs for memory safety bugs in the Rust standard library. We got responses that suggest to request CVE numbers on our own for publicly discolsed bugs.

From Steve Klabnik:

(...)
3. Usually, this group's job is to help triage incoming, sensitive
bugs. Usually that has correlated with CVEs, and so we are the ones
ending up filing them, but there's an interesting governance question
here. Furthermore, the CVE system is kind of outside of the project
generally, that is, they don't actually require that the project is
the one to request a CVE, though they do ask that reporters talk to
vendors first, as you're doing here, mostly to minimize duplicates.

I would be interested in hearing what Josh and Pietro have to say
here. Thanks for raising this; this is new territory for us, and so I
don't have an immediate good answer.

From Josh Stone:

(...)
I agree that issues which are already public probably don't need to involve this group. I do think we would like to be aware of all Rust Project CVEs though, so we're not caught off guard.

If there are new security implications realized about an old bug fix, maybe we would still want private disclosure. I can think of a few cases of kernel bugs that were quietly fixed, and then made a huge stink about security later.

We replied that we would like to proceed and request CVE number on our own and provided a list of bugs of memory safety bugs in the standard library that we think worth it to have CVE numbers for. We requested CVEs through MITRE CVE Request web form (https://cveform.mitre.org/) on March 15th, but haven't heard back anything yet.

[Qwaz]

Right now, memory safety bugs in the Rust standard library are underrepresented than a bug in a toy crate on crates.io. The conclusion of the last attempt (#561) to file RustSec advisory for std bugs was to try requesting a CVE number before creating a RustSec advisory. Unfortunately, having a CVE as prerequisite seems to possess significant delay in the process.

Question to RustSec maintainers: Should we reconsider the CVE requirement, considering the importance of public awareness of memory safety bugs in the Rust standard library? Some of the ways I can think of is to announce a RustSec advisory with a placeholder that can be replaced with CVE numbers later or to assign a RustSec ID first and put CVE in alias field just like other advisories.

[Qwaz]

id-map was reported to RustSec on April 2nd and got CVE on April 7th, in 5 days. 3.5 weeks seems unusual...

[tarcieri]

@Qwaz sounds like a good use case for CNA. Unfortunately core asked us to pause our discussions regarding getting one from MITRE until we can figure out what a project-wide CNA might look like.

That does seem unusual for it to take so long.

[Qwaz]

Unfortunately core asked us to pause our discussions regarding getting one from MITRE until we can figure out what a project-wide CNA might look like.

Does "getting one" mean becoming a CNA or getting a CVE ID?

---

We can definitely use the CNA process once RustSec becomes a CNA. But considering that there are quite a few std bugs blocked by the CVE assignment right now, I was wondering if it makes sense to consider an alternative approach such as assigning RustSec ID first to std bugs while waiting for the CVE response.

[Qwaz]

Received 8 CVE numbers on April 11th. I'll create PRs for them.
CVE-2015-20001, CVE-2021-28875, CVE-2021-28876, CVE-2021-28877, CVE-2021-28878, CVE-2021-28879, CVE-2021-36317, CVE-2021-36318

[tarcieri]

Does "getting one" mean becoming a CNA or getting a CVE ID?

A CNA

[Qwaz]

Four more CVEs have been assigned. With these, all Rust standard library memory safety bugs that I know are covered. I'll close the issue once these bugs are added to RustSec database.
CVE-2017-20004, CVE-2018-25008, CVE-2020-36323, CVE-2021-31162

[Qwaz]

Created a repository to track CVEs and soundness bugs for the Rust standard library.
https://github.com/Qwaz/rust-cve