A turning point for CVE numbers [LWN.net]

A turning point for CVE numbers

Posted Feb 15, 2024 6:22 UTC (Thu) by kees (subscriber, #27264)
In reply to: A turning point for CVE numbers by bluca
Parent article: A turning point for CVE numbers

The more I've watched the conversations around this announcement, the more I suspect that the "middle path" outcome will be switching to using the Common Vulnerability Scoring System (CVSS) for assessing the "applicability" of CVEs.

There are currently no plans to assign CVSS scores from cve@kernel.org, so this may happen externally, which kind of puts things back to square one: external entities will call out specific fixes as "important", and the cherry-picking will continue.

Honestly, when I would do security flaw lifetime analysis, I only ever looked at "Critical" and "High" CVEs (as rated by the Ubuntu security and kernel teams), since there was already such a giant long tail of "Medium" and "Low". E.g. see slides 4 & 5:
https://outflux.net/slides/2021/lss/kspp.pdf

to post comments

A turning point for CVE numbers

Posted Feb 15, 2024 10:59 UTC (Thu) by bluca (subscriber, #118303) [Link] (2 responses)

That would be sensible, however, if the kernel is its own CNA, are external entities allowed to do that? I thought the point was that they wouldn't be anymore?

A turning point for CVE numbers

Posted Feb 15, 2024 13:44 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

The point is that, because the kernel is a CNA, doing anything with kernel vulnerabilities requires you to either get the kernel team to issue the CVE number, CVSS score etc, or show MITRE that you engaged the kernel team, and they refused to issue a CVE number, attach a CVSS score etc.

A CNA cannot block publication of CVEs in their product, nor can a CNA prevent a CVSS score being attached to a CVE it's responsible for. It just gets "first dibs" on dealing with the issue, but you can still go around them if they're being slow or obstructive. Most of the gain for the kernel is that this blocks the noise, because it blocks the zero-effort CNAs from issuing CVE numbers (or attaching CVSS scores) to a kernel vulnerability. These CNAs are the ones who'd happily issue a CVE for the same vulnerability in the source code once for each supported architecture, or put a 9.8/10.0 CVSS score on a vulnerability because if you have credentials to SSH as root to a host, you can exploit the vulnerability remotely.

A turning point for CVE numbers

Posted Feb 16, 2024 10:56 UTC (Fri) by taladar (subscriber, #68407) [Link]

Technically issuing distinct CVE numbers for the same vulnerability on different architectures would actually be useful to the people using the CVE numbers to judge impact, especially if only affected architectures get one. There is nothing worse than a security advisory for an issue you know can't affect you because you are using entirely different hardware (or in the case of non-kernel software entirely different host operating systems) to the one where the problem occurs.