[GHSA-jq66-xh47-j9f3] Type confusion if __private_get_type_id__ is overriden

[kornelski]

Updates

• Affected products
• CVSS
• Severity

[kornelski]

I appreciate GitHub is pulling in Rust security advisories, but calling this one "Critical" is crying wolf.

This vulnerability depends on the author of the software intentionally shooting themselves in the foot. It doesn't exist in any piece of software that hasn't already deliberately manually created a hole to exploit by writing incorrect code implementing a hidden function that is clearly named as something that isn't supposed to be manually implemented.

For this to be a remote code execution attack, an attacker would have to have ability to write new methods in victim's source code. It's the wrong side of the airtight hatchway.

[KamilaBorowska]

The CVSS rating for this vulnerability is correct as CVSS doesn't measure risk and is based on "worst possible scenario" for libraries. Yes, I agree it's dumb, but at this time GitHub Advisory Database uses CVSS ratings.

See also https://rust-lang.zulipchat.com/#narrow/stream/146229-wg-secure-code/topic/Too.20high.20CVSS.20scores.20for.20Rustsec for discussion on Rust Zulip.

[kornelski]

This policy is very problematic for GitHub as a product, because it incorrectly alerts me that my dependencies have a "Critical" vulnerability, when in practice this is a purely theoretical tiny wart that doesn't affect anything.

If GitHub insists on using an inappropriate severity metric, I won't be able to rely on these vulnerability notifications, since I can't jump on every case where some dependency was theoretically less than ideal in a scenario that never happens. It changes the vulnerability notification feature from a very useful tool to a distracting nuisance.

[darakian]

Hey @kornelski, as @xfix points out CVSS is not a system that we (github) control nor is this CVE one which we've assigned a score to. This CVE comes to us via mitre and we try to respect the decision making of others in the security community and the severity ranking they give to the advisories they score. If you would like to dispute the severity then please reach out to mitre and have this discussion with them. While I agree with you that this may be hard to exploit I also agree with mitre that the impact of a successful exploit would be very high.

If GitHub insists on using an inappropriate severity metric, I won't be able to rely on these vulnerability notifications

We aim to ensure that our users have the most complete view of any vulnerability relevant to them so that they can make decisions with the most complete information available. If you don't think this advisory is relevant then you're welcome to dismiss this advisory and it should remain hidden. In case you're unaware failure has been deprecated which is it's own reason one might want to avoid it.

[kornelski]

Thank you for your reply.

It's unfortunate that a series of reasonable individual decisions leads to a very poor result. It makes sense for mitre to state what's the worst-case scenario. It makes sense for you to trust mitre's assessments. It makes sense for you to collect security advisories and warn about them en masse. But the combination of these seemingly sensible decisions added up to a counter-productive situation where you have alerted me that my dependencies have a "Critical" vulnerability when in fact they are completely unaffected by this and there is absolutely nothing to be concerned about.