Live data from Hacker News

Dear Linux Kernel CNA, what have you done?

amanitasecurity.com

91–100 of 116 posts

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

#91
post #73

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.

Can’t speak for others, but I’m talking from some experience here triaging and reporting fwiw. Not that I’m notable :)

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

#92
post #90

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…

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

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

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

#93
post #64

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…

[flagged]

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

#94
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

Where is upstreams CVSS score ?

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

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

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. Physical: You need to be able to touch the machine.

I'll be the first to admit that it can be difficult for some new players to correctly score their system. The "AV" refers to the attackers perspective, not how the software is used, this is a common mistake that quite a lot of vendors make.

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

#96
post #63

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

Just to be clear, that the CVE assigner (CNA) believes are security related, not the person asking.

This is a CNA responsibility.

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

#97
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.

More importantly, how do you even get the reporters full report, not all vendors will supply this information, a lot of CVE data is lacking especially in closed source vendors.

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

#98
post #64

Earlier quoted context omitted.

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

[flagged]

No, they're not. They're assigning blame to people who are insisting that the CVE CNA's do the work of triaging issues for them without understanding what the issues are and whether they're applicable to their environment. An entirely justified --- and pretty mainstream! --- take on this issue.

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

#99
post #87
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…

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.

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

#100
post #90

Earlier quoted context omitted.

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

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.
Post reply on HN