The 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 behavior to accommodate them.
My first thought on reading "cybersecurity regulations" was whether this was going to be the EU at the root cause again. The legislation mentioned in the article seems to be 2x EU instruments.
The problem here seems to be fear over how EU legislators and judges will interpret CVEs more than anything the kernel is doing. Looks like a complex and legally risky situation; good luck to the EU devs, hope it stays as a theoretical concern. I imagine common sense will prevail and the law will be interpreted the sensible way.
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.
I think I agree. Erring in the direction of too many CVEs means that people trying to get bug fixes rolled out won’t need to deal with the dreaded “ok, we understand the problem, but we can’t actually fix it in our systems until it has a CVE” that comes all too often from distributors.
Has any one in this thread actually evaluated all ~320 CVEs since Feb 20? Because I have. And I literally just finished writing a filter script for MITRE's cve.org API output.
1. Most of the new CVEs have potential security concerns. At the very least, they would have been assigned a CVE if they were reported by an external researcher.
2. Many of them don't affect the older LTS branches.
3. I found 1 (1!) CVE that has a remote exploitation possibility. The rest are mostly local privilege exploit or DoS or crashes.
4. This Greg dude (heh) is backtracking to 2021 to flag bugs that have since been fixed. If your kernel repository is even semi up to date, you would have cut down the CVE count by 1/3.
In my company, the majority consensus amongst the kernel developers is 'patch your shit and do rolling release. We are too busy to evaluate all the CVEs.' On the opposite end, are embedded hardware kernel developers who barely had their kernels working on existing hardware. Both sides make good arguments and I don't have any opinion I'd share.
There are other ways to lessen the CVE workload.
1. Disable unused components with defconf or make menuconfig.
2. Don't stay on the bleeding edge branch (ie. 6.x)
3. Implement automatic minor version commit merges
Your mileage may vary, but with these implemented, the workload is managable imo.
> There are other ways to lessen the CVE workload.
> 1. Disable unused components with defconf or make menuconfig.
+1 for avoiding vulnerabilities, but were you saying this lessens the CVE evaluation workload? I'd love to hear about automation for evaluating CVEs based on a kernel config. I've done a fair amount of that manually and I'm not aware of any metadata in the CVE records (or in the CVE json in gregkh's new vulns repo) that includes config metadata.
While I understand the problems raised in this post, I think they're going a bit too far. The CVEs assigned to the kernel were already specific to various parts of it. You're not running linux-x.y.z, but rather linux-x.y.z + specific config. That means vendors already needed to look at CVEs and decide what applies to them and what doesn't. It's up to NVD records to include how likely something is to be a problem and give it some description / score.
Choosing a random selection of CVEs posted so far... they look reasonable. They're actual issues and they'll potentially affect someone.
This reminds me of the cookie banners situation. Many people complain about the cookie banners being visible rather than about the companies doing things that requires them to notify you. Now if you say you care about the published vulnerabilities, you get to actually see them all. And potentially change the policies around how you worked with them. (yes, it's not a great analogy, I'm not blaming linux for having each of those vulnerabilities)
> Typically, security researchers are held to higher standards when disclosing vulnerabilities. The expectation is that CVEs are assigned for ‘meaningful’ security vulnerabilities, and not for any software fixes that ‘might’ be a security vulnerability.
Maybe that's the aspiration, but it's clearly not the case in practice.
I reported a firefox bug 12 years ago where a malicious SVG could cause a hang - basically a 22-year-old XML bomb, adapted to SVG patterns. My bug turned out to be a duplicate of a 16 year old firefox bug.
No way of stealing user data. No sandbox escape. Not a crash that might indicate a buffer overrun. With a process per tab, it doesn't even crash the browser. It's just a file that takes a very long time to load - and it's not even an image type that user-generated-content sites like facebook and reddit allow you to upload. Reasonably enough, 12 years ago it was triaged as a minor performance issue.
12 years ago, Firefox wasn't multi process. So your bug would likely freeze the entire browser, including the UI. Considering that, back then, Firefox reloaded all tabs back when you reopened it, it would keep freezing even if you force closed it. Fun times.
Good. Forcing downstream consumers of open source projects to spend resources on identifying and fixing security issues is not just entirely appropriate, but direly needed.
If you're already paying someone to maintain Linux for you, this shouldn't be causing that much trouble; it might need some contractual adjustments but you're already set up to get a stream of "good" updates. The patch frequency may be higher, but other people already do the majority of the work for you.
If you were just ingesting Linux "for free"… well, tough luck. You're profiting from the work of others already, you don't get to complain about not being spoon fed exactly what you need.
In practice, a small number of commercial entities (likely a mix of commercial distributions and designated security companies) will probably offer "Linux as a service". People could do the same work on their own, but that's not cost effective.
Either way, this shift in responsibilities has been long overdue.
Linux as a service is most of Redhat and Canonical's business models.
grsecurity does this from a security angle specifically - in fact they're boasting about it on their homepage right now (fair enough!)
>Are Your Products Drowning in Linux Kernel CVE Noise?
>We know your products can't be updated every week based off unverified CVE information. Address true risk by protecting against entire classes of vulnerabilites and exploitation techniques. Our Pro Support ensures you make the most of attack surface reduction and our proactive defense in your products.
Having a large number of new, unscored, CVEs in the Linux kernel is going to make things... interesting. From their lists https://lore.kernel.org/linux-cve-announce/ these just have a CVE and not really enough detail for anyone to assign a score without a lot of additional analysis, which reduces their usefulness.
To an extent it could be suggested they're just exposing an existing flaw in the system (CVSS scores which may be taken to be scientifically applied, are actually just matters of opinion in many cases), but it will cause a lot of problems with automated tooling and compliance.
> Notably, SyzScope has classified 183 bugs out of 1,170 fuzzerexposed bugs as high-risk. KOOBE has managed to generate 6 new exploits for previously non-exploitable bugs.
While the rate is low it does show that some bugs were indeed exploitable without that being known to the kernel devs. If an attacker is willing to invest more time than the kernel devs combing through commits to find vulnerabilities in the some older stable kernel then a big unlabeled pile saying "there's probably a vulnerability in there, go update" is correct.
This way of thinking is how almost everyone approaches CVEs, but is also out of date now. There are millions of open source projects (tens of millions really). This attitude of treating security bugs as some sort of special snowflake isn't realistic
There are easily hundreds of thousands of security vulnerabilities fixed every year that get no IDs because the current process is rooted in security from 1999 (the number is probably way way higher, but you get the idea)
Rather than obsessing over individual vulnerability IDs, we should be building systems that treat this data as one of many inputs to determining risk
It's possible to take a somewhat unopinionated approach to CVSS, the issue is that such CVSS scores exist in a vacuum, and vulnerabilities exist in environments. It's not possible to really apply a CVSS score to a vulnerability in a specific environment without understanding the vulnerability and more or less ignoring the CVSS score.
In summary, CVSS scores can be very objective, but in those cases they're also worthless.
I cannot really speak to the "Radio Equipment Directive", but what the author claims or implies with regards to the Cyber Resilience Act is not correct.
These Annexes explain the imposed Vulnerability Handling Processes imposed on manufacturers. The EU obviously only speaks about _exploitable_ vulnerabilities, because they know the problems of the CVE system all too well.
Best of all, open source projects are actively excluded by the CRA. [2]
"Open source projects will not be required to directly implement the mandated processes described in the CRA. But every commercial product made available in the EU which is built on top of those open source projects will."
CVE DOS - aka denial of service through legislative/regulatory requirements instead of technical attack is going to be fun.
Edit: by that I mean filing bogus report or just non-security related CVEs. That is also reason why a lot of projects are trying to register themselves as CNA (see curl etc).
It's going to be fun when companies pick Windows instead of Linux because it doesn't cause an awful to handle patch cycle in contexts where things have to work within some regulatory bounds (that make pointless updates cost a lot of time, effort and money, maybe even cause risk to human life).
I 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.
Oh great, now the previously lazy companies will pressure researchers to "not have discovered" bugs due to the legislatively required response to anything put into the system formally... and we will start hearing, "I don't use open source because it involves triage of too many CVEs. Michaelsoft never gives my engineers mandatory work."
This article largely misses the point from the Linux kernel's point of view.
They have always said "Every bug is a security bug". I don't know about more global content, but at Kernel Recipes (2019?) gregkh took a Pixel that was running latest Google security patches that contained all CVEs. Then looked at non-CVE patches he merged in his LTS. And it took him less than an hour to find a DoS vulnerability.
I understand the author's frustration from the Linux Kernel community to not want to classify bugs, but the reality is that a huge portion of the bug fixes are actually security fixes [1], so between requiring 20% of the patches to be merged, and 100%, is there really a point?
The author mentions Cyber Resilience Act, and I believe that Linux Kernel team created this CNA /on purpose/ to have an impact on the CRA. They believe that the only way to have a secure Linux Kernel is to have an up-to-date Linux kernel. (cf https://social.kernel.org/notice/ARWvggnOvXny0CUCIa ). With the CRA enacted, doing such a every-bug-is-a-security-bug CNA is a way for them to enforce their view.
[1] FWIW, my personal opinion there is that this shows that Linux's monolith architecture is getting old, but I see nothing that could reasonably replace it. I think that "the dream" would be to have a LKL-like linux "arch" to compile every driver as an independent process of Hurd, with GKI-like stable-ish ABI.
> They have always said "Every bug is a security bug".
If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong.
If everything is a CVE, nothing is. That approach just wastes a lot of time and effort making people not so familiar with the codebase (as the maintainers) do triage.
> Kroah-Hartman put up a slide showing possible "fixes" for CVE numbers. The first, "ignore them", is more-or-less what is happening today. The next, option, "burn them down", could be brought about by requesting a CVE number for every patch applied to the kernel.
They intend to burn down the cve system, and complaining about it is not a plan to stop it.
"burn them down" is kind of a brilliant political move.
on one hand, it's true to the "all bugs are security bugs (and the converse is obviously true)" position.
on the other hand, it will demonstrably cause hassles for what i term the "checklist security" people. "oh noes we only have the budget for N CVEs per release and we must have NONE > $arbitrary-number". and so that's a very good thing because checklist-security like that is far worse than nothing at all.
on the the other-other hand, in more legitimate, well engineered downstream user, a CVE for every bug may conversely actually help real security. "all" you have to do is evaluate every single potential security flaw's real actual applicability and impact for your use case. and if you can't afford that - faking it with a check-the-box mentality is no substitute. but maybe you can afford that? if so better data will probably help, not hurt.
finally, the other concrete improvement is that the people closest to the product will be able to more accurately judge the CVE score and more quickly correct outliers. a local privilege escalation that requires enhanced privileges to execute is not an 8. i'd much rather have 1000 CVEs with appropriate scores than 10 that are massively overrated and stupid. of course, a simple one-dimensional metric is hogwash anyway, but - baby steps.
It is often difficult to assess the consequences of a bug, especially in large and complicated project like an OS kernel. It could take lot of time, and it is easier just to fix the bug and err on the safe side by calling it a potential "vulnerability". Especially when nobody pays a bounty for proof-of-concept.
I 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
Is it true that the Linux Kernel has traditionally deprecated the idea of "security bugs"? I thought the kernel crew took the view that a bug is a bug.
So perhaps this policy is a kind of spoiler response to efforts to require all security bugs to have a CVE allocated.
[+] [-] tptacek|2 years ago|reply
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 behavior to accommodate them.
[+] [-] roenxi|2 years ago|reply
The problem here seems to be fear over how EU legislators and judges will interpret CVEs more than anything the kernel is doing. Looks like a complex and legally risky situation; good luck to the EU devs, hope it stays as a theoretical concern. I imagine common sense will prevail and the law will be interpreted the sensible way.
[+] [-] tsujamin|2 years ago|reply
[+] [-] amluto|2 years ago|reply
[+] [-] guardiangod|2 years ago|reply
1. Most of the new CVEs have potential security concerns. At the very least, they would have been assigned a CVE if they were reported by an external researcher.
2. Many of them don't affect the older LTS branches.
3. I found 1 (1!) CVE that has a remote exploitation possibility. The rest are mostly local privilege exploit or DoS or crashes.
4. This Greg dude (heh) is backtracking to 2021 to flag bugs that have since been fixed. If your kernel repository is even semi up to date, you would have cut down the CVE count by 1/3.
In my company, the majority consensus amongst the kernel developers is 'patch your shit and do rolling release. We are too busy to evaluate all the CVEs.' On the opposite end, are embedded hardware kernel developers who barely had their kernels working on existing hardware. Both sides make good arguments and I don't have any opinion I'd share.
There are other ways to lessen the CVE workload.
1. Disable unused components with defconf or make menuconfig.
2. Don't stay on the bleeding edge branch (ie. 6.x)
3. Implement automatic minor version commit merges
Your mileage may vary, but with these implemented, the workload is managable imo.
[+] [-] mmc|2 years ago|reply
> 1. Disable unused components with defconf or make menuconfig.
+1 for avoiding vulnerabilities, but were you saying this lessens the CVE evaluation workload? I'd love to hear about automation for evaluating CVEs based on a kernel config. I've done a fair amount of that manually and I'm not aware of any metadata in the CVE records (or in the CVE json in gregkh's new vulns repo) that includes config metadata.
[+] [-] viraptor|2 years ago|reply
Choosing a random selection of CVEs posted so far... they look reasonable. They're actual issues and they'll potentially affect someone.
This reminds me of the cookie banners situation. Many people complain about the cookie banners being visible rather than about the companies doing things that requires them to notify you. Now if you say you care about the published vulnerabilities, you get to actually see them all. And potentially change the policies around how you worked with them. (yes, it's not a great analogy, I'm not blaming linux for having each of those vulnerabilities)
[+] [-] Avamander|2 years ago|reply
So many vendors don't and it's tedious to say the least.
[+] [-] throwaway11460|2 years ago|reply
[+] [-] michaelt|2 years ago|reply
Maybe that's the aspiration, but it's clearly not the case in practice.
I reported a firefox bug 12 years ago where a malicious SVG could cause a hang - basically a 22-year-old XML bomb, adapted to SVG patterns. My bug turned out to be a duplicate of a 16 year old firefox bug.
No way of stealing user data. No sandbox escape. Not a crash that might indicate a buffer overrun. With a process per tab, it doesn't even crash the browser. It's just a file that takes a very long time to load - and it's not even an image type that user-generated-content sites like facebook and reddit allow you to upload. Reasonably enough, 12 years ago it was triaged as a minor performance issue.
Apparently in 2023, this counts as a CVE.
[+] [-] gertop|2 years ago|reply
[+] [-] Arch-TK|2 years ago|reply
Lots of corps would spend a non-trivial amount of effort to remediate something with such a score.
[+] [-] eqvinox|2 years ago|reply
If you're already paying someone to maintain Linux for you, this shouldn't be causing that much trouble; it might need some contractual adjustments but you're already set up to get a stream of "good" updates. The patch frequency may be higher, but other people already do the majority of the work for you.
If you were just ingesting Linux "for free"… well, tough luck. You're profiting from the work of others already, you don't get to complain about not being spoon fed exactly what you need.
In practice, a small number of commercial entities (likely a mix of commercial distributions and designated security companies) will probably offer "Linux as a service". People could do the same work on their own, but that's not cost effective.
Either way, this shift in responsibilities has been long overdue.
[+] [-] Retr0id|2 years ago|reply
grsecurity does this from a security angle specifically - in fact they're boasting about it on their homepage right now (fair enough!)
>Are Your Products Drowning in Linux Kernel CVE Noise?
>We know your products can't be updated every week based off unverified CVE information. Address true risk by protecting against entire classes of vulnerabilites and exploitation techniques. Our Pro Support ensures you make the most of attack surface reduction and our proactive defense in your products.
https://grsecurity.net/
[+] [-] bhaney|2 years ago|reply
Then change that definition and stop operating off of it. It has never been correct.
[+] [-] Retr0id|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] raesene9|2 years ago|reply
Having a large number of new, unscored, CVEs in the Linux kernel is going to make things... interesting. From their lists https://lore.kernel.org/linux-cve-announce/ these just have a CVE and not really enough detail for anyone to assign a score without a lot of additional analysis, which reduces their usefulness.
To an extent it could be suggested they're just exposing an existing flaw in the system (CVSS scores which may be taken to be scientifically applied, are actually just matters of opinion in many cases), but it will cause a lot of problems with automated tooling and compliance.
[+] [-] the8472|2 years ago|reply
While the rate is low it does show that some bugs were indeed exploitable without that being known to the kernel devs. If an attacker is willing to invest more time than the kernel devs combing through commits to find vulnerabilities in the some older stable kernel then a big unlabeled pile saying "there's probably a vulnerability in there, go update" is correct.
[+] [-] aryca|2 years ago|reply
There are easily hundreds of thousands of security vulnerabilities fixed every year that get no IDs because the current process is rooted in security from 1999 (the number is probably way way higher, but you get the idea)
Rather than obsessing over individual vulnerability IDs, we should be building systems that treat this data as one of many inputs to determining risk
[+] [-] Arch-TK|2 years ago|reply
In summary, CVSS scores can be very objective, but in those cases they're also worthless.
[+] [-] _tk_|2 years ago|reply
These Annexes explain the imposed Vulnerability Handling Processes imposed on manufacturers. The EU obviously only speaks about _exploitable_ vulnerabilities, because they know the problems of the CVE system all too well.
Best of all, open source projects are actively excluded by the CRA. [2] "Open source projects will not be required to directly implement the mandated processes described in the CRA. But every commercial product made available in the EU which is built on top of those open source projects will."
[1]: https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-...
[2]: https://eclipse-foundation.blog/2023/12/19/good-news-on-the-...
[+] [-] mnau|2 years ago|reply
Edit: by that I mean filing bogus report or just non-security related CVEs. That is also reason why a lot of projects are trying to register themselves as CNA (see curl etc).
[+] [-] Avamander|2 years ago|reply
[+] [-] pingubob|2 years ago|reply
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.
[+] [-] whatshisface|2 years ago|reply
[+] [-] phh|2 years ago|reply
They have always said "Every bug is a security bug". I don't know about more global content, but at Kernel Recipes (2019?) gregkh took a Pixel that was running latest Google security patches that contained all CVEs. Then looked at non-CVE patches he merged in his LTS. And it took him less than an hour to find a DoS vulnerability.
I understand the author's frustration from the Linux Kernel community to not want to classify bugs, but the reality is that a huge portion of the bug fixes are actually security fixes [1], so between requiring 20% of the patches to be merged, and 100%, is there really a point?
The author mentions Cyber Resilience Act, and I believe that Linux Kernel team created this CNA /on purpose/ to have an impact on the CRA. They believe that the only way to have a secure Linux Kernel is to have an up-to-date Linux kernel. (cf https://social.kernel.org/notice/ARWvggnOvXny0CUCIa ). With the CRA enacted, doing such a every-bug-is-a-security-bug CNA is a way for them to enforce their view.
[1] FWIW, my personal opinion there is that this shows that Linux's monolith architecture is getting old, but I see nothing that could reasonably replace it. I think that "the dream" would be to have a LKL-like linux "arch" to compile every driver as an independent process of Hurd, with GKI-like stable-ish ABI.
[+] [-] Avamander|2 years ago|reply
If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong.
If everything is a CVE, nothing is. That approach just wastes a lot of time and effort making people not so familiar with the codebase (as the maintainers) do triage.
I hope they get burnt quick by this approach.
[+] [-] sour-taste|2 years ago|reply
The relevant part:
> Kroah-Hartman put up a slide showing possible "fixes" for CVE numbers. The first, "ignore them", is more-or-less what is happening today. The next, option, "burn them down", could be brought about by requesting a CVE number for every patch applied to the kernel.
They intend to burn down the cve system, and complaining about it is not a plan to stop it.
[+] [-] fargle|2 years ago|reply
on one hand, it's true to the "all bugs are security bugs (and the converse is obviously true)" position.
on the other hand, it will demonstrably cause hassles for what i term the "checklist security" people. "oh noes we only have the budget for N CVEs per release and we must have NONE > $arbitrary-number". and so that's a very good thing because checklist-security like that is far worse than nothing at all.
on the the other-other hand, in more legitimate, well engineered downstream user, a CVE for every bug may conversely actually help real security. "all" you have to do is evaluate every single potential security flaw's real actual applicability and impact for your use case. and if you can't afford that - faking it with a check-the-box mentality is no substitute. but maybe you can afford that? if so better data will probably help, not hurt.
finally, the other concrete improvement is that the people closest to the product will be able to more accurately judge the CVE score and more quickly correct outliers. a local privilege escalation that requires enhanced privileges to execute is not an 8. i'd much rather have 1000 CVEs with appropriate scores than 10 that are massively overrated and stupid. of course, a simple one-dimensional metric is hogwash anyway, but - baby steps.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] throwawaaarrgh|2 years ago|reply
[+] [-] codedokode|2 years ago|reply
[+] [-] bogota|2 years ago|reply
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
[+] [-] denton-scratch|2 years ago|reply
So perhaps this policy is a kind of spoiler response to efforts to require all security bugs to have a CVE allocated.
[+] [-] motohagiography|2 years ago|reply
Cynically, I'd bet there are more than a few less technical but academic operators on the board who would run this play.
[+] [-] dang|2 years ago|reply
Linux Is a CVE Numbering Authority (CNA) - https://news.ycombinator.com/item?id=39406088 - Feb 2024 (10 comments)
The Linux kernel project becomes a CVE numbering authority - https://news.ycombinator.com/item?id=39361511 - Feb 2024 (24 comments)
[+] [-] unknown|2 years ago|reply
[deleted]