Why is the kernel so special?
Why is the kernel so special?
Posted Jun 19, 2024 19:29 UTC (Wed) by SLi (subscriber, #53131)Parent article: How kernel CVE numbers are assigned
> One question that crops up from time to time can be summarized as: "why are we so overzealous and why can't we only create CVEs for severe security fixes?"; the answer is that quality assessment is an impossible task. Since the kernel is infinitely configurable and adaptable, it's not possible to know all the ways in which it could be deployed and utilized. Evaluating potential vulnerabilities and associating generic levels of bug reachability, severity, and impact is infeasible.
I have hard time imagining the kernel is particularly special here compared to any other complex piece of software. Sure, users can make arbitrarily silly decisions like keep usernames secret and publish passwords. I think it's perfectly fine to say that any user that does so gets to keep the breakage.
Posted Jun 19, 2024 21:18 UTC (Wed)
by flussence (guest, #85566)
[Link] (31 responses)
1. The CVE system is a farce if it completely melts down over a single project releasing a few hundred of them over the course of several months.
People who put this much stock in CVEs will apparently fall for a road tunnel painted onto a cliff face, and that kind of sums up most of the security industry. It's all prayer and superstition obfuscated through tech jargon.
Posted Jun 19, 2024 21:24 UTC (Wed)
by jikos (subscriber, #43140)
[Link] (30 responses)
Posted Jun 19, 2024 22:10 UTC (Wed)
by pizza (subscriber, #46)
[Link] (29 responses)
The _only_ path forward is for folks that care about this stuff to acknowledge that they don't want _software_, they want an ongoing _service_, with correspondingly different economic properties.
This means they have to, on an ongoing basis, expend the resources to (a) continually evaluate everything in their supply chain themselves, or (b) pay someone else to do it for them. As opposed to the current status quo of (c) expecting someone else to do it for them, for free, indefinitely.
Posted Jun 20, 2024 0:53 UTC (Thu)
by DemiMarie (subscriber, #164188)
[Link] (1 responses)
Posted Jun 20, 2024 6:45 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
Posted Jun 20, 2024 9:03 UTC (Thu)
by mstsxfx (subscriber, #41804)
[Link] (26 responses)
Posted Jun 20, 2024 10:03 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (25 responses)
The issue is that the rules for being a CNA require you to issue a CVE for all vulnerabilities in your product, regardless of severity; the only way for downstreams to reduce the number of CVEs the kernel CNA issues is to find a convincing way to explain that a given bug is not a vulnerability.
A CNA that claims responsibility for a project must issue CVE numbers for all vulnerabilities it knows about in its project, or lose its CNA status. In return for this, the CVE Program grants CNAs the right to block other CNAs from issuing CVE numbers for vulnerabilities in their projects. Previously, no CNA claimed responsibility for the Linux kernel, so while anyone could issue a CVE number for it, nobody was required to; now the kernel CNA claims responsibility for the Linux kernel, and thus has to issue CVE numbers for it, but now a separate security researcher can't get another CNA to issue a CVE number for the kernel (or convincing the CNA of last resort that the kernel CNA is refusing to issue a CVE number for bogus reasons).
And note that if the CNA of last resort issues too many CVE numbers for a project, the CNA that claimed it stops being a CNA. Similar applies if the CVE Program discovers that a CNA is not issuing CVE numbers for vulnerabilities in projects it claims, even if those vulnerabilities are low severity.
A lot of the noise around this process comes from people simply not understanding how the CVE Program is meant to work, because the kernel has been outside it for so long.
Posted Jun 20, 2024 12:35 UTC (Thu)
by msmeissn (subscriber, #13641)
[Link] (24 responses)
https://www.cve.org/ResourcesSupport/AllResources/CNARules
> 4.2.2.1 CNAs SHOULD assign a CVE ID if:
> the CNA has reasonable evidence to determine the existence of a Vulnerability (4.1), and
> 4.2.2.2 CNAs SHOULD Publicly Disclose and assign a CVE ID if the Vulnerability:
> has the potential to cause significant harm, or
There is also a clause on if reporters come to your CNA you SHOULD take their input seriously, and if you do not assign they can go to your root CNA tree.
Also likely interesting for you, as you are NOT following it:
> 4.2.7 CNAs SHOULD assign CVE IDs to Vulnerabilities, not Fixes for Vulnerabilities.
> CNAs SHOULD assign CVE IDs whether or not a Fix is available.
So basically you should prove a vulnerability before you assign a CVE.
Posted Jun 20, 2024 12:58 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (23 responses)
I'm not Greg. Please don't be rude by misnaming me, unless your intention is to offend.
My read of those rules is that the kernel is following them; there is a vulnerability, it's publicly disclosed by the fix, and the kernel is assigning a CVE number to it.
AFAICT, none of the kernel CNA assigned CVE numbers are going to things that are not a vulnerability; the complaint is that the kernel is assigning CVE numbers to "minor" vulnerabilities that are "too hard" to exploit.
And I'm not a CNA at all, so what I do is irrelevant.
Posted Jun 20, 2024 13:18 UTC (Thu)
by gioele (subscriber, #61675)
[Link] (2 responses)
Proposal: A group of people that dislike the current approach gets together and nominates one "minor" vulnerability that is "too hard to exploit". The Linux Foundation then announces a high-5-digit USD bounty for an exploit for that specific vulnerability.
If the bounty is not claimed in one month the Linux CNA is asked to tune down their approach.
If the bounty is claimed, then the whole discussion about "minor" vulnerabilities is put to rest.
Posted Jun 20, 2024 13:46 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (1 responses)
Given the one-off costs of exploiting some vulnerabilities, 5-digit USD (no more than $99,999) isn't enough and one month from nomination to exploit isn't enough, either. Low 7-digit USD would be - at least $1,000,000, and a year would be more practical than a month, to allow motivated parties to find the exploit.
Note that the reason I say that 5-digit USD is not enough is that many vulnerabilities will require you to build hardware to exploit them - for example, CVE-2021-47329 would need you to design, debug, and build a Thunderbolt 3 to FPGA board so that you could exploit it. While the board's BOM price is about $250, you can expect to spend much more than that during the debugging stage unless you already have the tools needed to debug PCIe and Thunderbolt hardware - protocol analyzers to let you monitor the USB4/Thunderbolt 3 traffic and the PCIe traffic to/from your FPGA are going to set you back about $20,000 in total, for example.
Similarly, while debugging you won't want to be buying one-off builds of your board design; you'll want to pay for about 10 populated units, so that you don't wait the full turnaround time (typically a month for cheap manufacturers) for a new board if there's a manufacturing issue caused by a marginal design, but can discard the faulty boards and just use the ones that work well enough for testing.
Posted Jun 21, 2024 3:15 UTC (Fri)
by wtarreau (subscriber, #51152)
[Link]
Posted Jun 20, 2024 14:38 UTC (Thu)
by mstsxfx (subscriber, #41804)
[Link] (19 responses)
I do not agree with this statement. Let's put aside CVEs that got successfully disputed (that requires engineering time to do btw.). Just to give couple of examples
This is not an exhaustive list of course. It is possible to assign CVSS 0 to those CVEs but as already mentioned elsewhere. Every downstream has to do that evaluation which costs a lot of engineering time all that with dubious if any actual value IMHO.
Posted Jun 20, 2024 14:57 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (18 responses)
I look at the fix for CVE-2023-52596, and it's clearly exploitable by anyone who can load LKMs into the running kernel. And that makes it a vulnerability where the CVE Program rules say it should be given a CVE number, albeit one with a very low severity.
Same applies to fixes in tests; CVE numbers aren't just for "production environments", they're for all vulnerabilities in projects. You're arguing that because the test cases "shouldn't" be run, vulnerabilities in them shouldn't be reported, contrary to CVE Program rules.
And the whole "WARN_ON" story isn't about CVEs, AFAICT - you're pointing to something that's not a CVE number, and using that to argue that the kernel is too eager to assign CVE numbers. All the CVEs I can find that have WARN_ON mentioned in them are cases where there's a security vulnerability separate to the WARN_ON; some are cases where the WARN_ON body is itself wrong, some are cases where code after the WARN_ON assumes that the WARN_ON did not fire.
What you seem to be complaining about is all stuff where the CVE Program rules are intended to assign CVE numbers. And that's not the kernel CNA's fault - that's the CVE Program rules.
Posted Jun 20, 2024 15:33 UTC (Thu)
by mstsxfx (subscriber, #41804)
[Link] (17 responses)
Anyone who can load LKM in to running kernel can do whatever to the kernel. Your security just ended there!
[...]
> What you seem to be complaining about is all stuff where the CVE Program rules are intended to assign CVE numbers. And that's not the kernel
As has been explained elsewhere this is not really the case. CVE rules do not dictate anything like that. Sure you can argue to an extreme but please keep in mind that CVEs are there to have a practical meaning. The more they are diverging from that the less useful they are.
Posted Jun 20, 2024 15:42 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
In other words, something should be only considered a vulnerability if there are no other [potential] vulnerabilities, got it.
Posted Jun 20, 2024 15:48 UTC (Thu)
by corbet (editor, #1)
[Link] (1 responses)
Posted Jun 20, 2024 16:24 UTC (Thu)
by mstsxfx (subscriber, #41804)
[Link]
Posted Jun 20, 2024 15:48 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (13 responses)
My security only ended if someone can load an arbitrary LKM into the kernel; the kernel has a bug where an LKM without a security bug itself can cause a vulnerability to exist in the system, and that's pretty much the definition of a vulnerability that needs a CVE number.
The explanation you've given elsewhere contradicts what the rules say, and also the way CVE Program people have told me the rules are meant to be understood. You are supposed to issue CVE numbers for all known vulnerabilities, because the goal of the CVE Program is to provide a quick shorthand for talking about vulnerabilities.
So, you can quickly say, "this kernel has CVE-2023-52596", which tells the person loading an apparently safe LKM that the kernel has a bug that will turn into a vulnerability when this LKM is loaded, even though the LKM does not have vulnerabilities itself, and if you rebuilt it for a kernel without CVE-2023-52596, loading it would be safe.
And that's all that the CVE Program aims to do; classifying CVEs by how dangerous they are is the CVSS program, which is separate precisely because the CVE Program does not want to be limited to "dangerous" vulnerabilities, but wants to give you a quick way to refer to all vulnerabilities.
Posted Jun 20, 2024 16:50 UTC (Thu)
by mstsxfx (subscriber, #41804)
[Link] (12 responses)
Kernel module interfaces have never been designed to be defensive. The core kernel trusts the module is using them properly. The above mentioned CVE has potential security implications iff kernel module or built in code creates an empty sysctl directory. Which no kernel code in the tree does.
Protection against theoretical out-of-tree modules using kernel interfaces incorrectly has never been a concern - out of tree modules are not even recognized as supported by the kernel community in fact. Creating CVEs for issues like that simply doesn't make much sense.
Anyway, it seems that our views of what CVEs are supposed to represent are way too distant to find a common ground. So I leave it at that.
Posted Jun 20, 2024 16:57 UTC (Thu)
by pizza (subscriber, #46)
[Link] (8 responses)
I feel the need to point out that *neither* of your views matter here. The only ones whose views actually matter are the ones running the Linux kernel CNA, and like it or not, they have made their policies clear.
Posted Jun 20, 2024 17:10 UTC (Thu)
by mstsxfx (subscriber, #41804)
[Link]
Posted Jun 21, 2024 6:51 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (4 responses)
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,
Posted Jun 21, 2024 7:46 UTC (Fri)
by SLi (subscriber, #53131)
[Link] (3 responses)
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.
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.
Posted Jun 21, 2024 8:41 UTC (Fri)
by mstsxfx (subscriber, #41804)
[Link] (1 responses)
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.
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.
Posted Jun 21, 2024 9:53 UTC (Fri)
by zdzichu (subscriber, #17118)
[Link] (1 responses)
Posted Jun 21, 2024 14:37 UTC (Fri)
by zdzichu (subscriber, #17118)
[Link]
Posted Jun 20, 2024 17:00 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (2 responses)
If we're able to exclude vulnerabilities from consideration because "we don't support that use of the product", then virtually all buffer overflows can be excluded as "unsupported", since you sent data to the product outside its supported cases. Unless you're willing to argue that one, saying "Protection against theoretical out-of-tree modules using kernel interfaces incorrectly has never been a concern - out of tree modules are not even recognized as supported by the kernel community in fact" is the same as saying "protection against theoretical clients that send too much data incorrectly has never been a concern - unapproved clients are not even recognised as supported by the project community in fact".
Posted Jun 21, 2024 1:39 UTC (Fri)
by foom (subscriber, #14868)
[Link] (1 responses)
Posted Jun 21, 2024 8:12 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
I just declare that unapproved clients must not be allowed to connect to the service, so it's unsupported. That then puts me in the same place as the kernel not supporting out-of-tree modules - you're doing something unsupported, ergo it's not a vulnerability if the sysadmin chooses to install an unapproved client.
Why is the kernel so special?
2. The CVE system has always been a farce because Debian's security team didn't give two craps about exposing its users and downstreams to libav for years, while ffmpeg received hundreds of CVE fixes.
Why is the kernel so special?
Why is the kernel so special?
Why is the kernel so special?
Why is the kernel so special?
Why is the kernel so special?
Kernel CNA acts as required by CVE rules
Kernel CNA acts as required by CVE rules
> the Vulnerability has been or is expected to be Publicly Disclosed, and
> the CNA has appropriate scope (3.1).
> requires action or risk assessment by parties other than the CNA or Supplier.
Kernel CNA acts as required by CVE rules
Kernel CNA acts as required by CVE rules
Bounty for an exploit
Bounty for an exploit
Kernel CNA acts as required by CVE rules
> assigning CVE numbers to "minor" vulnerabilities that are "too hard" to exploit.
- CVE-2023-52596 - there is no upstream kernel code that could trigger the failure so we are talking about unknown 3rd party modules.
- Fixes in tests getting CVEs with a very vague argument that somebody is running them in production environments. I find this really dubious justification because even if somebody does that it is mostly shooting their own feet. I fail to see a security threat. Sure you can shoot your machine down by running tests in the kernel space but it is not an untrusted entity to run those tests if this is a production system.
- the whole WARN_ON story because somebody might be running panic_on_warn (as we cannot assume usecases). WARN* are defined and used to flag recoverable conditions. panic_on_warn is a debugging tool to trigger kdump early to do analysis! Whoever runs with panic_on_warns deliberately makes decision to panic the system on recoverable conditions. That doesn't resemble security vulnerability by far because the only fix for that is to remove all WARN*. Plugging one at the time doesn't make the system safer.
Kernel CNA acts as required by CVE rules
Kernel CNA acts as required by CVE rules
> vulnerability where the CVE Program rules say it should be given a CVE number, albeit one with a very low severity.
> CNA's fault - that's the CVE Program rules.
Kernel CNA acts as required by CVE rules
I would read that more like "something should only be considered a vulnerability if the system is not already fully compromised".
Module loading
Module loading
Kernel CNA acts as required by CVE rules
Kernel CNA acts as required by CVE rules
> cause a vulnerability to exist in the system, and that's pretty much the definition of a vulnerability that needs a CVE number.
Kernel CNA acts as required by CVE rules
Kernel CNA acts as required by CVE rules
Kernel CNA acts as required by CVE rules
Wol
Kernel CNA acts (or not?) as required by CVE rules
Changing the CNA rules
Kernel CNA acts (or not?) as required by CVE rules
Next improvement to the process
Kernel CNA acts as required by CVE rules
Kernel CNA acts as required by CVE rules
Kernel CNA acts as required by CVE rules
Kernel CNA acts as required by CVE rules
Kernel CNA acts as required by CVE rules