6 ms·

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

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.

tptacek 3y ago
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 accommodate that abuse; that just harms everybody else who isn't abusing it.
- gnfargbl 3y ago
  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?
  - saagarjha 3y ago
    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.
    - gnfargbl 3y ago
      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 presently have, however terrible it is, and with HN justifying the bonfire on the basis that CVEs were always broken anyway.
      - tptacek 3y ago
        "Universal bug identifier" is precisely the point of CVE. They're not "broken" anymore than a WONTFIX bug is.
        gnfargbl 3y ago
        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.
        tptacek 3y ago
        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.
        gnfargbl 3y ago
        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.
        _tk_ 3y ago
        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.
  - pdonis 3y ago
    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.
- tsujamin 3y ago
  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
  - tptacek 3y ago
    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.
    - tsujamin 3y ago
      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
      - tptacek 3y ago
        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.
        some_furry 3y ago
        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 looks like a sev:crit. The known alternative to CVSS is to rate severity levels entirely on vibes, and I find vibes to be more accurate.
- arp242 3y ago
  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.
  - tptacek 3y ago
    CVEs are categorically not "high impact bugs you probably want to get fixed ASAP". If you want that, make a new enumeration.
    - orf 3y ago
      > When millions of people understand a term "wrong", then that becomes "correct" on virtue of it being so widely used
      - Macha 3y ago
        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.
    - gnfargbl 3y ago
      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.
mike_d 3y ago
> because they are inputs into other processes CVEs should never be the input to anything except a triage pipeline, which in turn feeds other processes. If you don't have a competent pair of eyeballs (either internally or from a vendor) looking at CVEs with the context of how the impacted product is used in your organization, all you are doing is busy work. Almost all end user organizations (not software vendors, OS distributors, etc) should pretend CVEs don't exist. Blindly apply all your OS and software patches within 24 hours of them being available and be done with it. You are much more likely to suffer a business loss as the result of a vulnerability than you are a patch application.
Macha 3y ago
> 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".
- tracker1 3y ago
  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.
- worthless-trash 3y ago
  [flagged]
  - tptacek 3y ago
    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.
pdonis 3y ago
> 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.
deleted 3y ago
[deleted]

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.

tptacek 3y ago

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 accommodate that abuse; that just harms everybody else who isn't abusing it.

gnfargbl 3y ago
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?
- saagarjha 3y ago
  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.
  - gnfargbl 3y ago
    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 presently have, however terrible it is, and with HN justifying the bonfire on the basis that CVEs were always broken anyway.
    - tptacek 3y ago
      "Universal bug identifier" is precisely the point of CVE. They're not "broken" anymore than a WONTFIX bug is.
      - gnfargbl 3y ago
        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.
        tptacek 3y ago
        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.
        gnfargbl 3y ago
        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.
        _tk_ 3y ago
        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.
- pdonis 3y ago
  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.
tsujamin 3y ago
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
- tptacek 3y ago
  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.
  - tsujamin 3y ago
    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
    - tptacek 3y ago
      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.
      - some_furry 3y ago
        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 looks like a sev:crit. The known alternative to CVSS is to rate severity levels entirely on vibes, and I find vibes to be more accurate.
arp242 3y ago
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.
- tptacek 3y ago
  CVEs are categorically not "high impact bugs you probably want to get fixed ASAP". If you want that, make a new enumeration.
  - orf 3y ago
    > When millions of people understand a term "wrong", then that becomes "correct" on virtue of it being so widely used
    - Macha 3y ago
      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.
  - gnfargbl 3y ago
    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.

mike_d 3y ago

> because they are inputs into other processes CVEs should never be the input to anything except a triage pipeline, which in turn feeds other processes. If you don't have a competent pair of eyeballs (either internally or from a vendor) looking at CVEs with the context of how the impacted product is used in your organization, all you are doing is busy work. Almost all end user organizations (not software vendors, OS distributors, etc) should pretend CVEs don't exist. Blindly apply all your OS and software patches within 24 hours of them being available and be done with it. You are much more likely to suffer a business loss as the result of a vulnerability than you are a patch application.

Macha 3y ago

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

tracker1 3y ago
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.
worthless-trash 3y ago
[flagged]
- tptacek 3y ago
  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.

pdonis 3y ago

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

deleted 3y ago

[deleted]