Kernel CNA acts as required by CVE rules

Posted Jun 21, 2024 6:51 UTC (Fri) by Wol (subscriber, #4433)
In reply to: Kernel CNA acts as required by CVE rules by pizza
Parent article: How kernel CVE numbers are assigned

Actually, their views don't matter either!

The only views that matter are the views of the top-level CNA - the people who set the rules.

As others have pointed out, if the linux guys don't follow those rules, their CNA status will be taken away and we'll be back to the status quo ante, where ANY CNA can issue a linux CVE, and nobody in the linux community has any say at all.

We can bikeshed all we like about whether the rules are sensible, but unless you're prepared to try and change the rules, whinging about Greg and co following the rules is a waste of hot air ...

Cheers,
Wol

Kernel CNA acts (or not?) as required by CVE rules

Posted Jun 21, 2024 7:46 UTC (Fri) by SLi (subscriber, #53131) [Link] (3 responses)

I'm not sure. If one wants a change, a lot of affected people complaining that (my paraphrase:) the previous approach was useful to them but the current one is useful to nobody sounds like pretty useful activity. It may be conducive to any combination of rule changes; changes in how the rules are interpreted (there are pretty clear and sufficiently substantiated allegations in these comments that the claim that the CNA rules absolutely mandate the current approach is simply not true); or even parallel approaches to tracking vulnerabilities springing up and potentially eventually being similarly (misguidedly or not) mandated to be considered as parts of some processes.

I think it's clear that there are lots of people who were happier with the previous approach. Whether that was reasonable or not is a very good question; if the reality is, as the kernel devs seem to be arguing, that it basically resulted in paper pushing and checkmarks for a false sense of security, then probably those people should not be enabled. Having said that, I find it a difficult allegation to accept at face value that Linux distribution security teams are essentially either clueless or malicious.

What is unclear to me if there are any people who are happy with the current approach. Well, except maybe in the sense that they are happy that those paper pushers are stymied. Instead the justification seems to be (whether true or not) that "the rules require this".

TBH, I can see, from the kernel security team POV, the justification. I think it's this (correct me if wrong): What the distribution security teams were doing is harmful to security because it leads to the mistaken idea that anything but the latest stable kernel can be secure. Thus, this is a way to pressure them to move to the latest stable kernel, making up-to-date installations of Linux more secure (which is a very reasonable goal).

But at the same time, I do think it's fair to consider that pretty mean. "We think what Linux distributions are doing doesn't work, so we spend some extra effort to sabotage it" doesn't sound so benign to me.

Changing the CNA rules

Posted Jun 21, 2024 8:27 UTC (Fri) by farnz (subscriber, #17727) [Link]

The hard question for any rules change: what rules change would permit the kernel CNA to not issue CVEs for genuine vulnerabilities that only affect a small number of users, while not permitting a motivated vendor to disguise serious issues under the same rubric?

The current rules prohibit that by saying that if it's a vulnerability, even a minor one, even one that only affects a tiny subset of users, it gets a CVE number. That means that once a vendor knows they have a vulnerability, whether or not it's fixed, they're expected to issue a CVE number for it in due course; as a result, every vulnerability in a product claimed by a CNA can be talked about in terms of its CVE number.

If the CVE Project changes the rules to allow you to refuse to issue CVE numbers unless you have a "serious" issue (for whatever definition of "serious" it chooses), then you give vendors an incentive to describe all their vulnerabilities as "not serious"; we already see this with the CVSS scoring vendors give their own vulnerabilities, where it's common for some vendors to downplay the severity of the vulnerability compared to independent scorers, in the hope of disguising the issue.

And that leads to another point; anyone who only cares about "serious" vulnerabilities can already limit themselves by refusing to consider CVEs with low CVSS scores, either overall or in the areas they care about. That limits you to only the vulnerabilities that have been analysed and determined to be a significant risk, leaving the "noise" behind.

Kernel CNA acts (or not?) as required by CVE rules

Posted Jun 21, 2024 8:41 UTC (Fri) by mstsxfx (subscriber, #41804) [Link] (1 responses)

> the previous approach was useful

Let me just clarify on this. The previous approach had many flaws and problems as well. Going all the way back would be just a regression. It is really nice to see a better transparency (https://git.kernel.org/pub/scm/linux/security/vulns.git). It is also much better that the kernel community is involved (although there are improvements possible in that). I think the main improvement to the current process would be to start evaluating actual vulnerabilities rather than just tagging code fixes. That will certainly require more than 3 people in the team!

I think it would also help to agree on who those CVEs are actually created for because that might help to scope the land. It is really easy to keep arguing to the extreme but I do not think this is helpful in any way. There is nothing like 100% security. What really matters are threat models that people actually care about. There are many of them and it is really great to talk to those people. Assuming we cannot assume anything will very unlikely help none of them though because they will just be constantly flooded with stuff they mostly do not care about.

Sorry if that sounds like wasting a hot air but I really do care about having a useable CVE model.

Next improvement to the process

Posted Jun 21, 2024 9:27 UTC (Fri) by farnz (subscriber, #17727) [Link]

I think the next missing piece is getting people to work together on providing (partial or full) CVSS vectors for all kernel CVEs; then, individual consumers of CVEs can filter on components of the CVSS vector so far to determine whether they spend any time on this (which can be automated).

For example, the sysctl table vulnerability is almost certainly going to have AV:L, PR:H and UI:R in its vector; you need a local account to trigger it, and you need high privileges to load LKMs, which don't just appear on the system themselves, but need user interaction to make available or to load into the kernel.

This then spreads the load of determining which vulnerabilities are serious; as a distro security team, you contribute to CVSS vectors, and then use them to decide what you're going to do - you might, for example, decide that because of the intended use cases for your distro, if a vulnerability has PR:H and UI:R in its vector, it's not considered further, or that AV:L and AV:P vulnerabilities are low priority for detailed assessment.

It's important to note that my suggestion is that people who care contribute parts of CVSS vectors, not scores. It should be perfectly fine for you to say "this is PR:H, UI:R, so I'm stopping here", and for a security team that cares about PR:H vulnerabilities in the kernel to pick up from there and add the rest of the vector.