I think I speak for the whole 0day and 1day market when I say "Thank you Linux"
Dear Linux Kernel CNA, what have you done?
61–70 of 116 posts
Re: Dear Linux Kernel CNA, what have you done?
#62Earlier quoted context omitted.
It does not matter, because the signal was never there or meant to be there to begin with. CVEs solve a problem of multiple researchers and developers talking past each other about the same vulnerability (or vulnerable subsystem or line of code). It has never been a reliable enumeration of vulnerabilities. Organizations triaging CVEs line-by-line are abusing the system. The system should not bend itself to accommodat…
you’re missing the CVSS aspect which is intrinsically tied to CVE issuance (atleast when issued through the CNA-LR). It’s not _just_ an identifier, it’s a entirely valid and useful tool of triage and classification
CVSS is a Ouija board. Nobody takes it seriously. It was also introduced long after CVEs were. And even if it was meaningful --- it isn't, but stipulate --- it wouldn't change the fundamental point of CVEs.
Re: Dear Linux Kernel CNA, what have you done?
#63Earlier quoted context omitted.
Some platforms do in fact do this. If you run the entire stack, more power to you. But the kernel is forked by a hundred different people and everyone has their own bug trackers for that, so having an identifier for a security bug is actually useful to unify those.
I would have no problem at all with the kernel developers introducing the concept of a "universal bug identifier," and developing a system for cataloguing and managing those UBIDs. I would also have no issue with CVEs being replaced by a set of flags on those UBIDs, which people could take notice of or ignore as they saw fit. I do have a problem with the kernel devs attempting to burn down the only system we presentl…
"Universal bug identifier" is precisely the point of CVE. They're not "broken" anymore than a WONTFIX bug is.
Re: Dear Linux Kernel CNA, what have you done?
#64The purpose of CVEs is to ensure that people discussing vulnerabilities are talking about the same thing. CVEs aren't a checklist, they aren't a perfect enumeration, and it shouldn't matter if a CVE is issued for a nonissue. People who are burdened by requirements to ship (or produce rolling updates) to address every Linux kernel CVE are living in a state of sin. It doesn't make sense for the kernel CNA to alter its…
It does matter, because they are inputs into other processes, and the signal to noise has gone down. There’ll be a lot more time wasted in orgs triaging non-security-relevant bugs in the future.
> There’ll be a lot more time wasted in orgs triaging non-security-relevant bugs in the future.
The security team instituting those processes only have themselves to blame.
Have had to deal with too many rapid Jackson updates for "if you turn on the insecure mode that nobody turns on that lets the client specify the classes to instantiate and the documentation warns you about and requires a code change to enable, and include library X, then there's a new gadget that does RCE".
Re: Dear Linux Kernel CNA, what have you done?
#65I wonder how much time discussing if something is or isn’t a CVE has wasted.
As and end user if you don’t have a script that causes an exploit for a given CVE i don’t care. I have had to patch too many systems from hypothetical issues ASAP!! because management wants to look like they know something
Re: Dear Linux Kernel CNA, what have you done?
#66I think I speak for the whole 0day and 1day market when I say "Thank you for this idiocy, Linux community"
In their attempt to get revenge on security researchers for 'being more important', they have made it much easier for us to keep our exploits on the market for longer than before.
The idea that 'only the latest linux kernel is secure' is absolutely bananas, because it completely disregards the fact that legacy systems exist, they power very critical parts of our society, and they cannot be updated (as a general rule). Only components can be updated in-place.
So, again: thank you for the free money and for making exploits have a longer shelf life.
Re: Dear Linux Kernel CNA, what have you done?
#67Earlier quoted context omitted.
I would have no problem at all with the kernel developers introducing the concept of a "universal bug identifier," and developing a system for cataloguing and managing those UBIDs. I would also have no issue with CVEs being replaced by a set of flags on those UBIDs, which people could take notice of or ignore as they saw fit. I do have a problem with the kernel devs attempting to burn down the only system we presentl…
"Universal bug identifier" is precisely the point of CVE. They're not "broken" anymore than a WONTFIX bug is.
There's a good-faith community norm that CVEs are for bugs that the reporter believes are security-related. Sure, that norm is regularly violated, but community standards always are and it doesn't diminish their value.
Re: Dear Linux Kernel CNA, what have you done?
#68The purpose of CVEs is to ensure that people discussing vulnerabilities are talking about the same thing. CVEs aren't a checklist, they aren't a perfect enumeration, and it shouldn't matter if a CVE is issued for a nonissue. People who are burdened by requirements to ship (or produce rolling updates) to address every Linux kernel CVE are living in a state of sin. It doesn't make sense for the kernel CNA to alter its…
It does matter, because they are inputs into other processes, and the signal to noise has gone down. There’ll be a lot more time wasted in orgs triaging non-security-relevant bugs in the future.
> the signal to noise has gone down
As far as I can tell, the signal to noise has only "gone down" in the sense of "from really low to really, really low".
> There’ll be a lot more time wasted in orgs triaging non-security-relevant bugs in the future
It seems to me that even before this change there was a lot of time wasted in orgs triaging non-security-relevant bugs, because CVEs didn't carry much useful information before.
Re: Dear Linux Kernel CNA, what have you done?
#69Earlier quoted context omitted.
It does not matter, because the signal was never there or meant to be there to begin with. CVEs solve a problem of multiple researchers and developers talking past each other about the same vulnerability (or vulnerable subsystem or line of code). It has never been a reliable enumeration of vulnerabilities. Organizations triaging CVEs line-by-line are abusing the system. The system should not bend itself to accommodat…
Let's continue your reductive line of thinking. If the only purpose is to ensure that developers are talking about the same issue, then why does the kernel need need CVEs at all? Their existing bug tracking mechanisms should be entirely adequate, no?
In the 2019 article that is linked to in the LWN article posted upthread, that's exactly what Greg Kroah-Hartman suggested: use the change ID that the Linux kernel is already using as a vulnerability identifier.
Unfortunately, it does not appear that that proposal gained traction, since it's not discussed at all in the more recent LWN article.
Re: Dear Linux Kernel CNA, what have you done?
#70Earlier quoted context omitted.
"Universal bug identifier" is precisely the point of CVE. They're not "broken" anymore than a WONTFIX bug is.
There's a good-faith community norm that CVEs are for bugs that the reporter believes are security-related. Sure, that norm is regularly violated, but community standards always are and it doesn't diminish their value.
CVEs have been filed for e.g. memory corruption issues with no known exploit or even plausible path to exploit since time immemorial, or at least since time-since-CVE-was-invented. The idea that there is a burden of proof or certainty required to number something with a CVE is a commercial vendor invention.
It's easy to see why people want CVE to work that way! It implies that people numbering potential security issues are doing a fuckload of work for you. But that work isn't free, and CVE has other purposes in the research community. So, no, I don't think anybody is going to talk the kernel people down from this. They're right.
If you want a feed of "CVEs" that clear a plausibility bar, put that together yourself. A lot of people would love to consume it and sell it to their customers; you'll get a lot of uptake.