Linux Becomes a CVE Numbering Authority (Like Curl and Python). Is This a Turning Point? (kroah.com) 20
From a blog post by Greg Kroah-Hartman:
As was recently announced, the Linux kernel project has been accepted as a CVE Numbering Authority (CNA) for vulnerabilities found in Linux.
This is a trend, of more open source projects taking over the haphazard assignments of CVEs against their project by becoming a CNA so that no other group can assign CVEs without their involvment. Here's the curl project doing much the same thing for the same reasons. I'd like to point out the great work that the Python project has done in supporting this effort, and the OpenSSF project also encouraging it and providing documentation and help for open source projects to accomplish this. I'd also like to thank the cve.org group and board as they all made the application process very smooth for us and provided loads of help in making this all possible.
As many of you all know, I have talked a lot about CVEs in the past, and yes, I think the system overall is broken in many ways, but this change is a way for us to take more responsibility for this, and hopefully make the process better over time. It's also work that it looks like all open source projects might be mandated to do with the recent rules and laws being enacted in different parts of the world, so having this in place with the kernel will allow us to notify all sorts of different CNA-like organizations if needed in the future.
Kroah-Hartman links to his post on the kernel mailing list for "more details about how this is all going to work for the kernel." [D]ue to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team are overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team...
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. No CVEs will be assigned for any issue found in a version of the kernel that is not currently being actively supported by the Stable/LTS kernel team.
alanw (Slashdot reader #1,822) worries this could overwhelm the CVE infrastructure, pointing to an ongoing discussion at LWN.net.
But reached for a comment, Greg Kroah-Hartman thinks there's been a misunderstanding. He told Slashdot that the CVE group "explicitly asked for this as part of our application... so if they are comfortable with it, why is no one else?"
This is a trend, of more open source projects taking over the haphazard assignments of CVEs against their project by becoming a CNA so that no other group can assign CVEs without their involvment. Here's the curl project doing much the same thing for the same reasons. I'd like to point out the great work that the Python project has done in supporting this effort, and the OpenSSF project also encouraging it and providing documentation and help for open source projects to accomplish this. I'd also like to thank the cve.org group and board as they all made the application process very smooth for us and provided loads of help in making this all possible.
As many of you all know, I have talked a lot about CVEs in the past, and yes, I think the system overall is broken in many ways, but this change is a way for us to take more responsibility for this, and hopefully make the process better over time. It's also work that it looks like all open source projects might be mandated to do with the recent rules and laws being enacted in different parts of the world, so having this in place with the kernel will allow us to notify all sorts of different CNA-like organizations if needed in the future.
Kroah-Hartman links to his post on the kernel mailing list for "more details about how this is all going to work for the kernel." [D]ue to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team are overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team...
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. No CVEs will be assigned for any issue found in a version of the kernel that is not currently being actively supported by the Stable/LTS kernel team.
alanw (Slashdot reader #1,822) worries this could overwhelm the CVE infrastructure, pointing to an ongoing discussion at LWN.net.
But reached for a comment, Greg Kroah-Hartman thinks there's been a misunderstanding. He told Slashdot that the CVE group "explicitly asked for this as part of our application... so if they are comfortable with it, why is no one else?"
CVE = Common Vulnerabilities and Exposures (Score:5, Informative)
Re: (Score:1)
The fact that you were modded informative is a truly sad reflection of what Slashdot has become. This site has probably run close to 1000 stories related to CVEs over its time.
But yeah I get what we are now. So to follow up: Linux is an operating system developed Linus Torvalds, in case people are wondering. It's like Windows, except better and more loved on Slashdot.
Re:CVE = Common Vulnerabilities and Exposures (Score:4, Interesting)
I for one appreciate the explanation. I've been a software developer for 35 years, and on slashdot for a couple of decades, and didn't know. Maybe I wasn't paying attention, or maybe I was just more interested in different subjects. I'd mod the guy up too if I could.
Re: (Score:2)
Re: CVE = Common Vulnerabilities and Exposures (Score:1)
Re: (Score:2)
Okay surprising as that is I would then offer an alternative justification. If you've made it as both a software developer for 35 years and a Slashdotter, then maybe the knowledge of the acronym wasn't actually necessary. Kind of like how most people don't know laser is "Light Amplification by Stimulated Emission of Radiation" and are none the better for knowing that it is an acronym.
I'm just surprised it got explained now, after the countless stories we've had on CVEs.
Re: (Score:2)
I'll buy your thought process.
I do think there's a relatively simple explanation. We tend to pick out the stories that interest us. Being in the Windows world, I often skip right over the Linux ones (You know, like "Linux kernel 6.7.1.35 has been released." I really don't care about those, so I skip them entirely.) So it's likely that a sizable number of slashdot readers similarly skip over anything that says CVE in it, because they just don't care about that subject.
Re: (Score:2)
GNU is the OS, no? Linux is a kernel... while you're out there
Ready to be corrected by the 5-digit /.'ers as is tradition.
Linux threatens a lot of business models (Score:3)
Re:Linux threatens a lot of business models (Score:5, Funny)
You should probably report that vulnerability and get a CVE number assigned to it.
Re: (Score:2)
Re:Linux threatens a lot of business models (Score:5, Informative)
Ever since the age of cheap fuzzing, the number of CVEs assigned has exploded, but the number of "real" issues has stayed more or less the same.
It's worse than that: We have CVEs that originated from Corporate IT idiots that don't know how to configure filesystem permissions [nist.gov] and projects [kernel.org] that actually took the CVE seriously. [github.blog] (Bonus in that link: Another CVE issued because idiots don't know how the OS default behavior works, and they still haven't fixed their FS permissions.....)
Re: (Score:2)
Re: (Score:2)
Why is it not a CVE if some default installation of a piece of software doesn't set its permissions properly?
Because the filesystem permissions are to be set by the owner / system administrator and enforced by the OS. It's not the job of some random piece of software to do that for you. No software has a way of knowing who should access what without having infrastructure in place to support it, and asking questions to the system administrator to determine it. Any modern OS has that functionality built-in by default, and it is far better tested, more standardized, and well known by end users, administrators, and a
The Badge of Honor (Score:2)
Linux is by far the most useful software to be open source and I am sure that rubs people the wrong way. I’d assume that by assigning a high number of CVEs they can make the kernel appear insecure even though it is not. Probably just one of many ways to attack
If you’re implying that a large number of reported problems and insecurities would make consumers think twice about buying or using a product, might I present a counter argument; Microsoft Windows.
It’s kinda popular.
Re: (Score:2)
Finally, the year of the Linux desktop! (Score:2)
I mean, what else could have possibly kept it from reaching this milestone!
One part of CVE policy I don't like (Score:3)
This is one part of the way CVE's are issued (not specifically for the Linux kernel) that I don't like because I think it leads to people not being aware of vulnerabilities.
An example from non-kernel software, if you try and find vulnerabilities in PHP 7.4.33 you won't find any, not because there aren't any, but because it is end of life and no longer supported.
From then on you just get things like CVE-2023-3824 [mitre.org]
which an unknowing reader (and many automated security checking tools) may interpret as not effecting PHP 7.4.33.
I think it would be much better if there were some post end-of-life period for which CVEs are still created (either a fixed time period, or until a certain number of CVEs had been issued) so that the final version of end-of-life software doesn't seem magically immune to issues. If nothing else a few more red flags being thrown in security tools might help some people resource upgrades, a big red "vulnerability" often seems to be easier to motivate management with than "end of life"....
Re: (Score:2)
Why should anyone waste their time when the software you're using is inherently out of date, obsolete, unsupported and quite clearly dangerous to use.
There's no more point filing CVEs against ancient PHP than there is filing CVEs against Window 3.1 or 95. We know it's broken, beyond repair, will never be fixed, and should never be in production use. Why bother to catalogue HOW broken it is against pretty much every attack you want to try?
7.4 has been "security fixes only" for over 2 years and end of life
Re: (Score:2)
For the "time" part of that question I'd posit that in most cases it wouldn't take any additional time.
I don't particularly want to get bogged down in PHP 7.4, it was just a random example, but a git blame in the problematic code probably shows the code has been there untouched for a long time and it would be almost zero extra effort to include PHP 7.4.* in the CVE listing.
And I am not proposing it forever, just for a defined period or once some threshold of CVEs have