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

101–110 of 116 posts

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

#101

Post by tptacek »

_tk_ wrote: post #86
gnfargbl wrote: post #77

Earlier quoted context omitted.

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.

Yes, because vendors love the idea that "the community" is doing the job of digesting and distilling security issues for them, and all they have to do is slap a graphical interface on that data to charge $100k/yr to customers. There is absolutely no reason the Linux CNA should dignify that concern.

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

#102

Post by tsujamin »

tptacek wrote: post #100
tsujamin wrote: post #92

Earlier quoted context omitted.

How do you calculate that? How does the fact it’s an over-the-internet vs. network adjacent only exploitable? This is what CVSS is good for when applied accurately

The fact that every competent organization has slightly different brackets for those levels is only one of the many reasons why CVSS is a joke.

CVSS has consistent rules, but yeah then incentives that make people ignore particular rules (vulnerability chaining being the one that I’ve seen before) makes the public scores questionable sometimes. Still it’s a useful, if imperfect, tool in our industry I think.

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

#103

Post by tptacek »

tsujamin wrote: post #102
tptacek wrote: post #100

Earlier quoted context omitted.

The fact that every competent organization has slightly different brackets for those levels is only one of the many reasons why CVSS is a joke.

CVSS has consistent rules, but yeah then incentives that make people ignore particular rules (vulnerability chaining being the one that I’ve seen before) makes the public scores questionable sometimes. Still it’s a useful, if imperfect, tool in our industry I think.

No, CVSS does not have consistent rules. Even people who support CVSS don't claim it's consistent. It's deliberately designed so that organizations can make it say what they want/need it to.

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

#104

Post by orf »

tptacek wrote: post #99
arp242 wrote: post #87

Earlier quoted context omitted.

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…

CVEs are categorically not "high impact bugs you probably want to get fixed ASAP". If you want that, make a new enumeration.

> When millions of people understand a term "wrong", then that becomes "correct" on virtue of it being so widely used

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

#105

Post by gnfargbl »

tptacek wrote: post #99
arp242 wrote: post #87

Earlier quoted context omitted.

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…

CVEs are categorically not "high impact bugs you probably want to get fixed ASAP". If you want that, make a new enumeration.

They're also, equally categorically, not "a list of every bug in every system." If you want that, make a new enumeration.

As 'arp242 says, we need to consider what is useful. Pretending that all CVEs are severe and must be addressed immediately is not useful. Spamming the CVE database with every bug in your tracker is not useful.

Replacing CVEs (and CPEs, which are equally terrible) with something new would be extremely helpful. My question is, who funds that work? NIST currently appear to have NVD resourcing issues, based on the banner on their website.

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

#106

Post by tracker1 »

roenxi wrote: post #80
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…

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

Largely my thought as well. Not having a kennel CNA would be far more problematic than the approach outlined for the Kernel CNA team.

Also if interpreted correctly it should help mitigate legal risks for EU companies that rely on Linux that update regularly.

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

#107

Post by tracker1 »

Macha wrote: post #64
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.

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

Not to mention DevSecOps that only know enough to run certain tools but not understand enough that certain flags don't apply because the canned test doesn't work the same as your app.

In my specific example /auth was reverse procured to a completely separate app, and /auth/login/bad wouldn't show the same content as / ... And even after explaining their test is invalid they still escalate rather than fixing or removing that test. Leaving me to explain 3 more times asking the way.

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

#108

Post by graemep »

roenxi wrote: post #80
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…

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

One possible solution is for people in the EU to set up their own triaging system to triage Linux CVEs (and other CVEs, and maybe other sources of info) in line with EU law. There should be enough people affected willing to find something like this.

I am not clear how the law affects people outside the EU whose software is distributed in the EU (including open source software that is not covered by the exemptions).

>I imagine common sense will prevail and the law will be interpreted the sensible way.

I hope it will, but I would hate to be in the position of having to depend on that.

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

#109

Post by Macha »

orf wrote: post #104
tptacek wrote: post #99

Earlier quoted context omitted.

CVEs are categorically not "high impact bugs you probably want to get fixed ASAP". If you want that, make a new enumeration.

> When millions of people understand a term "wrong", then that becomes "correct" on virtue of it being so widely used

I don't think this applies here. People literally agree that CVEs are the identifiers beginning with CVE-xxxx published by CNAs. They don't for example, think they're ticket numbers from the Apache bug tracker. The fact that they use them as if the criteria for publishing a CVE was more rigid, doesn't actually make that criteria more rigid.

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

#110

Post by some_furry »

worthless-trash wrote: post #95
some_furry wrote: post #76

Earlier quoted context omitted.

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…

Maybe you've had bad experiences with some vendors doing analysis however it i documented here: https://www.first.org/cvss/v3.0/user-guide > Network vs Local vs Physical Network: It has to traverse the network stack. Adjacent: On the same physical network link, (usually this means the ability to send packets that are lower level than TCP/IP). Local: ability to execute code on the local machine as the starting point.…

> Maybe you've had bad experiences with some vendors doing analysis however

I've been on both sides of bug bounty programs over the years.

I've been in corporate meetings where CVSS was summoned to downgrade the severity of high-sev security bugs, when the standard procedure wasn't to use CVSS at all.

I've published my fair share of security bugs.

Hell, I've even talked extensively with Steve Coley about how CVE and CWE intersect with my own experience doing security research.

And that's just some of the stuff I've done under this handle.

My experience with CVSS has consistently shown it to be misused.

Maybe you have enough discipline to use CVSS as it was intended by its designers. The rest of the world does not, by and large.

The main problem with the CVSS is that it's a one-dimensional numeric scale that's meant to measure the kind of complexity that warrants a formal threat model, not a 0-10 rating.

Post reply on HN