You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RUSTSEC-2020-0036 (archived version), which advises that failure is deprecated, is marked as informational. The RustSec website's page for this advisory lists its CVSS score is 9.8, which, the website says, means this is a "CRITICAL" problem, in all-caps, with a red background. The website then goes into more detail, saying that the deprecatedness of failure enables a low-complexity attack, executable over the network, with high impact to confidentiality, integrity, and availability.
The original addition of this advisory (#368) does not show such alarm. This level of alarm appears to have been added by the addition of CVSS information for this and many other advisories in #1085.
It appears that this CVSS information was added in an automated manner because the advisory is linked to CVE-2020-25575. CVE-2020-25575 says it's about "Access of Resource Using Incompatible Type ('Type Confusion')" and references an unsoundness in failure reported by Qwaz (rust-lang-deprecated/failure#336), although it also mentions "compatibility hazards", which appears to be a reference to woboats's retrospective about failure, which, as far as I see, is hardly referring to any security problem in failure. (Is the CVE advisory confused?)
There are two conditions for a library bug to be triggered. (1) The target application should use the API in a vulnerable manner and (2) the attacker should find a way to trigger it (e.g., through a network packet). My impression is that NIST mainly focuses on the second part when assigning a CVSS score which sometimes results in an exaggerated score that does not align with the actual security impact.
The bug in failure should have no impact in reality because people would not use the API in the bug-triggering way (requires overriding a method that is clearly private). However, if a program indeed used failure crate in this way, it would become an easy attack vector for malicious attackers, and I think that is why NIST assigned high CVSS score for this bug.
Please note that this is just my interpretation. I don't know what exact strategy is used to assign a CVSS score.
(In case https://internals.rust-lang.org/t/16699/15 was partly referring to my remarks here, I'd like to clarify that I didn't mean to complain about the surfacing of CVSS information for libraries in general; rather, I meant to question whether RUSTSEC-2020-0036 (as opposed to RUSTSEC-2019-0036) should link itself to CVE-2020-25575, which — to my inexpert eyes — seems to correspond to RUSTSEC-2019-0036 instead.)
RUSTSEC-2020-0036 (archived version), which advises that
failure
is deprecated, is marked asinformational
. The RustSec website's page for this advisory lists its CVSS score is 9.8, which, the website says, means this is a "CRITICAL" problem, in all-caps, with a red background. The website then goes into more detail, saying that the deprecatedness offailure
enables a low-complexity attack, executable over the network, with high impact to confidentiality, integrity, and availability.The original addition of this advisory (#368) does not show such alarm. This level of alarm appears to have been added by the addition of CVSS information for this and many other advisories in #1085.
It appears that this CVSS information was added in an automated manner because the advisory is linked to CVE-2020-25575. CVE-2020-25575 says it's about "Access of Resource Using Incompatible Type ('Type Confusion')" and references an unsoundness in
failure
reported by Qwaz (rust-lang-deprecated/failure#336), although it also mentions "compatibility hazards", which appears to be a reference to woboats's retrospective aboutfailure
, which, as far as I see, is hardly referring to any security problem infailure
. (Is the CVE advisory confused?)CVE-2020-25575 is also linked by RUSTSEC-2019-0036, which is about rust-lang-deprecated/failure#336.
Am I right in thinking that the CVE link and associated CVSS information belong with RUSTSEC-2019-0036 and not RUSTSEC-2020-0036?
The text was updated successfully, but these errors were encountered: