5 ms·

The Linux kernel project becomes a CVE numbering authority

77 points by corbet 3y ago

corbet 3y ago
Just in case anybody is wondering if this is significant...think about the implications of tens of thousands of CVE numbers being assigned for every stable kernel patch. There will have to be changes in the ways people are dealing with these.
- philipwhiuk 3y ago
  The linux CNA will just mean 'bug' and it will be impossible to know how severe any of them are.
em-bee 3y ago
after the curl announcement i pretty much saw this one coming. as i commented there: https://news.ycombinator.com/item?id=39054152 https://news.ycombinator.com/item?id=39054152 noone should ever be able to file a CVE without the product owner having a say in this. filing a CVE should always include the party that is responsible for the vulnerability with proper checks and balances. the current process allows accusing someone without the accused having any ability to defend themselves. it was created with the expectations that only security experts who know what they are doing will file CVEs. that expectation has not held. this is pretty much why linus torvalds refused to announce when they fix security issues in the linux kernel.
- philipwhiuk 3y ago
  > noone should ever be able to file a CVE without the product owner having a say in this. That's a really stupid idea. CVEs track security vulnerabilities, not 'security vulnerabilities the product owner is prepared to admit to'. Imagine if Cisco decided they were going to be the CNA for Cisco devices just weren't going to issue any CVEs for any vulnerabilities in any Cisco devices, regardless of whether they're exploited or not.
  - em-bee 3y ago
    i am not saying that the product owner should be able to veto without being overridden, just that they should have a right to be heard, and that their response needs to be considered. i do realize that many businesses would rather hide any security issues instead of acknowledging them. so a simple "no" or no response from them would not be enough. but the current situation where we get a CVE for anything that is not proven to be safe (when giving that proof is very expensive to make) is also not helpful. the linux kernel and curl becoming their own CVE authority is a hack to work around a broken process.
    - eviks 3y ago
      Who would be able to override the product owner? If it's the party that files, then what changed?
      - em-bee 3y ago
        maybe a number of independent reviewers. kind of like we have reviewers for scientific papers, except i would make the list of reviewers known and attached to the CVE like signoffs on patches, including reviewers that reject the claims. (actually, that should be done for papers as well, but that's a different discussion) then you can evaluate the seriousness of any CVE not only by its assigned threat level but also by weighing who and how many people reviewed the claims. further there could be review levels, also similar to how bug reports are handled: new/incoming, triage, verified/reproduced, closed/unreproducible, fixed. that would allow further categorization and give people another way to evaluate if a CVE is serious.
      - marcus0x62 3y ago
        Within the existing system, I think MITRE should be able to override a CNA, but I don’t know that they can, just that they don’t appear to do so.
  - patmorgan23 3y ago
    There are "security researchers" who grep GitHub for the words 'password' or 'secret' and blindly file CVE's if they find any hits.
philipwhiuk 3y ago
Every bugfix in the kernel is now a CVE. That's awful. Every unfixed security issue is now no longer assigned a CVE until it's fixed. That's even worse.
- blibble 3y ago
  time for security researchers to drop CVEs and a start new scheme? how about: CVF
  - marcus0x62 3y ago
    http://notcve.org/about.html http://notcve.org/about.html
  - bombcar 3y ago
    Cv6 - 128 bits and never adopted.
    - vacuity 3y ago
      Never is a bit harsh. Just a few decades...and a few more.
- worthless-trash 3y ago
  This will be interesting, if another linux vendor assigns a CVE and upstream duplicates the older CVE usually takes presedence, and they need to mark it as a duplicate, more houskeeping than just assigning it when they know about it. I'm glad the LK finally has come to this conclusion, I dont care if it ends up exploding and using a lot of CVE's.. Good Work.
egberts1 3y ago
"No CVEs will be assigned for unfixed security issues in the Linux kernel, assignment will only happen after a fix is available as it can be properly tracked that way by the git commit id of the original fix." Linus Torvalds: "A bug is a bug." As a kernel developer of ATM driver, I couldn't careless if there is a bug, much less some public authority (t)outing my driver as buggy. They'll get fixed, unit-tested, and real-world live-tested for the next release.
peanut-walrus 3y ago
So because the cve system has a few problems that annoy the kernel developers they decided an appropriate response is to completely sabotage it? Mature, you guys.

77 points by corbet 3y ago

Just in case anybody is wondering if this is significant...think about the implications of tens of thousands of CVE numbers being assigned for every stable kernel patch. There will have to be changes in the ways people are dealing with these.

philipwhiuk 3y ago
The linux CNA will just mean 'bug' and it will be impossible to know how severe any of them are.

em-bee 3y ago

after the curl announcement i pretty much saw this one coming. as i commented there: https://news.ycombinator.com/item?id=39054152 https://news.ycombinator.com/item?id=39054152 noone should ever be able to file a CVE without the product owner having a say in this. filing a CVE should always include the party that is responsible for the vulnerability with proper checks and balances. the current process allows accusing someone without the accused having any ability to defend themselves. it was created with the expectations that only security experts who know what they are doing will file CVEs. that expectation has not held. this is pretty much why linus torvalds refused to announce when they fix security issues in the linux kernel.

philipwhiuk 3y ago
> noone should ever be able to file a CVE without the product owner having a say in this. That's a really stupid idea. CVEs track security vulnerabilities, not 'security vulnerabilities the product owner is prepared to admit to'. Imagine if Cisco decided they were going to be the CNA for Cisco devices just weren't going to issue any CVEs for any vulnerabilities in any Cisco devices, regardless of whether they're exploited or not.
- em-bee 3y ago
  i am not saying that the product owner should be able to veto without being overridden, just that they should have a right to be heard, and that their response needs to be considered. i do realize that many businesses would rather hide any security issues instead of acknowledging them. so a simple "no" or no response from them would not be enough. but the current situation where we get a CVE for anything that is not proven to be safe (when giving that proof is very expensive to make) is also not helpful. the linux kernel and curl becoming their own CVE authority is a hack to work around a broken process.
  - eviks 3y ago
    Who would be able to override the product owner? If it's the party that files, then what changed?
    - em-bee 3y ago
      maybe a number of independent reviewers. kind of like we have reviewers for scientific papers, except i would make the list of reviewers known and attached to the CVE like signoffs on patches, including reviewers that reject the claims. (actually, that should be done for papers as well, but that's a different discussion) then you can evaluate the seriousness of any CVE not only by its assigned threat level but also by weighing who and how many people reviewed the claims. further there could be review levels, also similar to how bug reports are handled: new/incoming, triage, verified/reproduced, closed/unreproducible, fixed. that would allow further categorization and give people another way to evaluate if a CVE is serious.
    - marcus0x62 3y ago
      Within the existing system, I think MITRE should be able to override a CNA, but I don’t know that they can, just that they don’t appear to do so.
- patmorgan23 3y ago
  There are "security researchers" who grep GitHub for the words 'password' or 'secret' and blindly file CVE's if they find any hits.

philipwhiuk 3y ago

Every bugfix in the kernel is now a CVE. That's awful. Every unfixed security issue is now no longer assigned a CVE until it's fixed. That's even worse.

blibble 3y ago
time for security researchers to drop CVEs and a start new scheme? how about: CVF
- marcus0x62 3y ago
  http://notcve.org/about.html http://notcve.org/about.html
- bombcar 3y ago
  Cv6 - 128 bits and never adopted.
  - vacuity 3y ago
    Never is a bit harsh. Just a few decades...and a few more.
worthless-trash 3y ago
This will be interesting, if another linux vendor assigns a CVE and upstream duplicates the older CVE usually takes presedence, and they need to mark it as a duplicate, more houskeeping than just assigning it when they know about it. I'm glad the LK finally has come to this conclusion, I dont care if it ends up exploding and using a lot of CVE's.. Good Work.

egberts1 3y ago

"No CVEs will be assigned for unfixed security issues in the Linux kernel, assignment will only happen after a fix is available as it can be properly tracked that way by the git commit id of the original fix." Linus Torvalds: "A bug is a bug." As a kernel developer of ATM driver, I couldn't careless if there is a bug, much less some public authority (t)outing my driver as buggy. They'll get fixed, unit-tested, and real-world live-tested for the next release.

peanut-walrus 3y ago

So because the cve system has a few problems that annoy the kernel developers they decided an appropriate response is to completely sabotage it? Mature, you guys.