Enable promoting informational advisories to vulnerabilities if CVE-aliased

[ranweiler]

The following example surprised me: the traitobject crate currently only gets flagged by cargo audit with an unsound warning (RUSTSEC-2020-0027), despite also having a critical CVE (CVE-2020-35881).

It looks like the aliasing CVE was published many months after the RustSec advisory was issued. The RustSec advisory was eventually updated to link to the CVE (along with many others: #542).

There is a larger (stalled?) discussion (#313) about the RustSec project's operational definition of "security vulnerability". However, for purposes of security automation, I'd like to split off a narrow suggestion: if a CVE alises an informational RustSec advisory, then that advisory should be effectively "promoted" to have type "Vulnerability".

Some ideas for implementing this "effective promotion":

• Remove the informational key in the advisory (is this sufficient?)
• Issue a new, non-informational advisory
• Add a cargo audit flag that locally enables this effective promotion, via something like --deny cve.

[ranweiler]

I lean toward the last idea of a cargo audit option. That lets conservative (or compliance-motivated) end users opt in to accepting the categorical (and debatable) policy of "CVE == actual vulnerability".

[Qwaz]

1. In my experience, RustSec informational advisories are similar to low-risk bugs in other languages. I also observed the similar interpretations in Rust forums a few times although I can't recall exact sources right now. RustSec describes informational advisories as "non-vulnerability" right now. I think it's better to update this description, but I don't think it's necessary to promote them to full advisories only because they have associated CVE numbers as long as the meaning of an informational advisory is clarified. I like the last option suggested in the description, --deny cve.

2. The "bug severity" from a CVSS score and the actual bug impact/risk do not always align. Library bugs, which are the majority of the bugs reported to RustSec, are context-sensitive by nature. A library bug requires the user of the library to use its API in a vulnerable way, and only then the attacker can exploit the bug. The CVSS score focuses more on the second part, "what happens if this bug is exploited". Since Rust unsafe bugs usually lead to memory safety bugs when exploited, they tend to get high CVSS scores. However, if we can conclude that it is not very likely that the API is used in a vulnerable way, I think it makes sense to assign informational advisories to them, and probably it might better align with what general people expect from "bug severity".

For instance, despite CVE-2019-25010 can only be triggered by actively overriding an undocumented trait function which is clear from its name that it is not meant to be overridden (__private_get_type_id__), it got "9.8 critical" score in NVD CVSS score. I think the situation is similar in CVE-2020-35881; Although the layout of a fat pointer is not "guaranteed" to be stable, it is not likely to change in the meantime, and if it changes, I'm pretty sure the Rust team will provide enough grace period, so that the ecosystem can safely migrate.

[ranweiler]

@Qwaz, nice analysis, and I agree with both points. I think point (2) about CVSS/impact misalignment is particularly important to take seriously (it's the main reason I prefer the --deny cve idea I mooted).

As a user: if there is an assigned CVE, I always want to at least know about it when I invoke cargo audit. In other words, I'd use it as signal that the advisory is worth extra scrutiny. In practice, I would probably use --deny cve in CI to alert via breaking the build, assess the actual advisory, and then either patch or ignore.

[tarcieri]

RustSec informational advisories are similar to low-risk bugs in other languages. I also observed the similar interpretations in Rust forums a few times although I can't recall exact sources right now. RustSec describes informational advisories as "non-vulnerability" right now.

What we were really trying to distinguish with informational = "unsound" vulnerabilities were the following cases:

1. Unsoundness in an API which results in a credible threat
2. Unsoundness in an API which is only a theoretical vulnerability which could be exploited by a malicious caller

This is still not a great distinction, however we've received various complaints about alert fatigue and various people felt quite strongly that 2 doesn't amount to an actual security vulnerability.

I have no problem promoting informational = "unsound" advisories to security advisories if there is any chance of real-world exploitation.

[pinkforest]

Converting this to discussions.