Shall standard library vulnerabilities also be in scope of cargo-audit?

[vi]

Example: https://www.reddit.com/r/rust/comments/9hssab/security_announcement_for_strrepeat/

[tarcieri]

We had a discussion about this on the Security WG kickoff call a few days ago. Some tentative takeaways were that:

1. RustSec should be folded into the Security WG
2. RustSec should track these types of vulnerabilities

[tarcieri]

There's a tentative plan to do this. I can propose a rough outline of what I'd have in mind for it:

1. Make a std/ directory in the toplevel of the repo which sits side-by-side with crates/
2. Use the same advisory format, but with std as the package name and the Rust version (i.e. the rustc version) as the version = ...
3. All std vulns must be identified by CVE-* (i.e. RUSTSEC-* is only for crate-level vulns). This is easy to implement as the rustsec crate already uses an enum for all vuln IDs which can handle several kinds of identifiers

After that, we'd need to find (or create) an authoritative list of all previous vulnerabilities in std, and potentially file retroactive CVEs for any of them which never received one.

[alex]

Quick skim of previously identified security issues in rust-core; only two of them are in std

• https://blog.rust-lang.org/2018/09/25/Rust-1.29.1.html - str::repeat vulnerability
• https://blog.rust-lang.org/2018/07/06/security-advisory-for-rustdoc.html rustdoc vulnerability
• https://blog.rust-lang.org/2016/11/10/Rust-1.13.html - dependency update for curl and openssl in cargo
• rust-lang/rust#44800 - VecDeque vulnerability

[tarcieri]

Okay so that's:

• str::repeat: CVE-2018-1000810
• rustdoc: CVE-2018-1000622
• VecDeque: CVE-2018-1000657

Not sure what to do about Rust 1.13 regarding a canonical identifier... I guess we could list all of the relevant vulns for those curl and openssl versions?

[alex]

CVE-2018-1000622 for the rustdoc one. I don't believe there's one for the cargo change (it's also not really notable IMO).

[Shnatsel]

I've thought about this for a while, and here's a bunch of things we could do about std or compiler vulnerabilities:

1. Alert people if their local compiler is vulnerable
2. Alert people if something installed via cargo was built with a vulnerable compiler version
3. Alert people if their crate uses a function that is known to be vulnerable in some compiler versions

I see (1) as more of a job for rustup than for cargo-audit. We can't just say that all versions before 1.29.1 are vulnerable, because e.g. Linux distributions backport security fixes. rustup is probably the only distribution method where vulnerable versions can be detected reliably, and it already syncs with a remote database and alerts you about updates, so that's probably where vulnerability notifications should go. This can also handle (2) by spitting out a command to rebuild all packages installed via cargo after installing a security update.

I'm not sure whether (3) is useful in any way. There's not much the crate maintainer can do about that. Well, he can add a minimum required version to the crate, but it's a waste of time to do that manually and may refuse to build for no reason on compilers with backported security fixes.

[tarcieri]

For a start, I'd like to get them catalogued somewhere, and write APIs to access them from the rustsec crate.

The itch I'd ultimately like to scratch for myself is being able to identify historical builds (e.g. container images) containing artifacts built with vulnerable versions of the compiler/std.

That said, I think it's fine for cargo-audit to do (1) at least for now. I think it'd be great to get it into rustup as well, and perhaps we can do that via the rustsec crate.

[Shnatsel]

I'm now even more interested in cataloguing these because it turns out that rustc already encodes its version in all executables it compiles.

Try strings /path/to/executable | grep 'rustc version'. But don't run strings on untrusted files.

[DevQps]

Just to bump to the original question!: Personally I think std should be in the scope of cargo audit as well. Since 'std' is a reserved crate name I wonder what would be against us putting it along side other crates as well? Maybe we could change RUSTSEC- to CVE-, but I don't think using RUSTSEC-* for std would be bad as well, since it is basically just like any other crate aside some special compiler integration maybe. Not differentiating too much from other crates will probably make future APIs easier to use.

But I might be wrong about all this though! However if we feel like they are not in the scope of cargo-audit we should probably close this issue.