Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear Linux Kernel CNA, what have you done?

amanitasecurity.com

Post reply on HN
Print view View original

81–90 of 116 posts

Re: Dear Linux Kernel CNA, what have you done?

#81

Post by [deleted] »

tsujamin wrote: post #52
tptacek wrote: post #47

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…

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.

[deleted]

Re: Dear Linux Kernel CNA, what have you done?

#82

Post by rincebrain »

gertop wrote: post #45
michaelt wrote: post #18

> 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 2…

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.

I actually kept such an SVG bomb around as a demonstration of how badly you could break browsers for many years, to anyone who claimed they were completely secure and unbreakable.

I should go see what happens if I load it now, since what changed was less that it stopped breaking them and more that I stopped having the conversation with many people...

Re: Dear Linux Kernel CNA, what have you done?

#83

Post by lokar »

tsujamin wrote: post #59
tptacek wrote: post #54

Earlier 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

For me, CVSS and the people who use it lost all credibility when they asked my team for a urgent update to patch… a pcmcia bug in the kernel of our EC2 instances.

Re: Dear Linux Kernel CNA, what have you done?

#84

Post by guardiangod »

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.

Re: Dear Linux Kernel CNA, what have you done?

#85

Post by _tk_ »

tptacek wrote: post #73
tsujamin wrote: post #72

Earlier quoted context omitted.

CVSS as practiced sucks sometimes, the rules around not chaining vulnerabilities to up a score are rarely followed, but as specified it’s actually a good system. Undercutting my own point though, it doesn’t hurt to rerun a calculation if you think the public vectors is “lacking” or if temporal/environmental metrics matter in your context

I would be interested in seeing a professional vulnerability researcher of any note jumping in here to make a defense of CVSS. I'd rebut, respectfully, if they did. But I don't expect it to happen, despite that there are plenty of researchers on HN. I feel like I'm on reasonably safe ground when I say that my take on CVSS is a mainstream one in the field.

I guess it depends on what field you are talking about. I'd say that the typical scores on CVEs can be helpful indicators, but that's really it. I'd agree with you, that everyone(?) in the field knows, that all players game the systems, e.g. Microsoft every patch Tuesday, or someone with a cool name for a vuln and a blog.

Re: Dear Linux Kernel CNA, what have you done?

#86

Post by _tk_ »

gnfargbl wrote: post #77
tptacek wrote: post #70

Earlier quoted context omitted.

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 issu…

It's an interesting idea, but I'm not sure the market is there for the "plausible CVE" replacement you mention. We already have EPSS and KEV, and we regularly see attempts to replace CVSS with something better -- Zoom did something recently, as did Vulncheck I think. They don't tend to get much traction.

All the tooling that's been integrated everywhere is reliant on CVEs and CVSS. All vendors issue their vulns with CVEs, not ZoomVEs. Disruption is not likely unfortunately.

Re: Dear Linux Kernel CNA, what have you done?

#87

Post by arp242 »

tptacek wrote: post #54
tsujamin wrote: post #52

Earlier quoted context omitted.

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.

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…

This reminds me a little bit of the people saying things like "actually, Java is not "True Object Oriented™* because it's not about messaging like in Smalltalk", and things like that. Well, okay, fine, but it seems undisputable that the phrase "Object Oriented" is used to describe OOP as implemented in Java. When millions of people understand a term "wrong", then that becomes "correct" on virtue of it being so widely used. I mean, modern English is just old English spoken badly by Vikings and Normans, right?

That's kind of how things work, and not much you or I can do about it.

So we need to think about "What is practical?" and "what is useful?", keeping these realities in mind, rather than insisting on "this is what it was meant to be".

Personally I think a good start would be to rethink the entire messaging and list them as "high impact bugs you probably want to get fixed ASAP", or something along those lines, rather than "security bugs". This should avoid the whole security wankery with memory issues that perhaps maybe possibly could perhaps someday lead a possible exploit maybe.

Re: Dear Linux Kernel CNA, what have you done?

#88

Post by _tk_ »

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."

[1]: https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-...

[2]: https://eclipse-foundation.blog/2023/12/19/good-news-on-the-...

Re: Dear Linux Kernel CNA, what have you done?

#89

Post by GrumpySloth »

To me the most disingenuous thing here on Linux’s part is that they won’t issue CVEs for vulnerabilities which aren’t fixed. And thus the latest Linux release is always tautologically CVE-free. Magic. Maybe at work I should raise the idea that our Jira bug tickets should have only one possible status: “fixed”. I’m learning from the best.

Re: Dear Linux Kernel CNA, what have you done?

#90

Post by tptacek »

some_furry wrote: post #76
tptacek wrote: post #73

Earlier quoted context omitted.

I would be interested in seeing a professional vulnerability researcher of any note jumping in here to make a defense of CVSS. I'd rebut, respectfully, if they did. But I don't expect it to happen, despite that there are plenty of researchers on HN. I feel like I'm on reasonably safe ground when I say that my take on CVSS is a mainstream one in the field.

I've only seen CVSS used by vendors to declare a lower severity rating than is warranted by an earnest understanding of a bug, and bug bounty hunters to do the opposite. For example, what does Network vs Local vs Physical mean if it's an exploit in a cloud microservice? Ooh let me consult the tea leaves. What's that? They consider it "Network" even though it's S3 mounted locally as a filesystem? Now that sev:med look…

I agree strongly. sev:{info,lo,med,hi,crit}. All you really need.
Post reply on HN