4 ms·

CVE assignment != security issue CVE numbers are just a way to ensure everyone is talking about the same bug. Not every security issue has a CVE, not every CVE

CVE assignment != security issue CVE numbers are just a way to ensure everyone is talking about the same bug. Not every security issue has a CVE, not every CVE is a security issue. Often, a regular bug turns out years later to have been a security issue, or a security issue turns out to have no security impact at all. If you want a central authority to tell you what to think, just use CVSS instead of the binary "does it have a CVE" metric.

skywhopper 2y ago
That’s definitely not the understanding that literally anyone outside the Linux team has for what a CVE is, including the people who came up with them and run the database. Overloading a well-established mechanism of communicating security issues to just be a registry of Linux bugs is an abuse of an important shared resource. Sure “anything could be a security issue” but in practice, most bugs aren’t, and putting meaningless bugs into the international security issue database is just a waste of everyone’s time and energy to make a very stupid point.
- kuschku 2y ago
  > including the people who came up with them How do you figure that? The original definition of CVE is exactly the same as how Linux approaches it. Sure, in recent years security consultants have been overloading CVE to mean something else, but that's something to fix, not to keep.
  - frankjr 2y ago
    Can you post the original definition?
    - vel0city 2y ago
      Common Vulnerabilities and Exposures
      - frankjr 2y ago
        Right but I was hoping for a definition which supports OP's claim that "CVE assignment != security issue".
        kuschku 2y ago
        Then check out these definitions, from 2000, defined by the CVE editorial board: > The CVE list aspires to describe and name all publicly known facts about computer systems that could allow somebody to violate a reasonable security policy for that system As well as: > Discussions on the Editorial Board mailing list and during the CVE Review meetings indicate that there is no definition for a "vulnerability" that is acceptable to the entire community. At least two different definitions of vulnerability have arisen and been discussed. There appears to be a universally accepted, historically grounded, "core" definition which deals primarily with specific flaws that directly allow some compromise of the system (a "universal" definition). A broader definition includes problems that don't directly allow compromise, but could be an important component of a successful attack, and are a violation of some security policies (a "contingent" definition). > In accordance with the original stated requirements for the CVE, the CVE should remain independent of multiple perspectives. Since the definition of "vulnerability" varies so widely depending on context and policy, the CVE should avoid imposing an overly restrictive perspective on the vulnerability definition itself. Under this definition, any kernel bug that could lead to user-space software acting differently is a CVE. Similarly, all memory management bugs in the kernel justify a CVE, as they could be used as part of an exploit.
        frankjr 2y ago
        > to violate a reasonable security policy for that system > with specific flaws that directly allow some compromise of the system > important component of a successful attack, and are a violation of some security policies All of these are talking about security issues, not "acting differently".
        josefx 2y ago
simiones 2y ago
This is completely false. The CVE website defines these very clearly: > The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities [emphasis mine]. In fact, CVE stands for "Common Vulnerabilities and Exposures", again showing that CVE == security issue. It's of course true that just because your code has an unpatched CVE doesn't automatically mean that your system is vulnerable - other mitigations can be in place to protect it.
- kuschku 2y ago
  That's the modern definition, which is rewriting history. Let's look at the actual, original definition: > The CVE list aspires to describe and name all publicly known facts about computer systems that could allow somebody to violate a reasonable security policy for that system There's also a decision from the editorial board on this, which said: > Discussions on the Editorial Board mailing list and during the CVE Review meetings indicate that there is no definition for a "vulnerability" that is acceptable to the entire community. At least two different definitions of vulnerability have arisen and been discussed. There appears to be a universally accepted, historically grounded, "core" definition which deals primarily with specific flaws that directly allow some compromise of the system (a "universal" definition). A broader definition includes problems that don't directly allow compromise, but could be an important component of a successful attack, and are a violation of some security policies (a "contingent" definition). > In accordance with the original stated requirements for the CVE, the CVE should remain independent of multiple perspectives. Since the definition of "vulnerability" varies so widely depending on context and policy, the CVE should avoid imposing an overly restrictive perspective on the vulnerability definition itself. For more details, see https://web.archive.org/web/20000526190637fw_/http://www.cve.mitre.org/About_CVE/About/exposures.html https://web.archive.org/web/20000526190637fw_/http://www.cve... and https://web.archive.org/web/20020617142755/http://cve.mitre.org/about/definition.html https://web.archive.org/web/20020617142755/http://cve.mitre.... Under this definition, any kernel bug that could lead to user-space software acting differently is a CVE. Similarly, all memory management bugs in the kernel justify a CVE, as they could be used as part of an exploit.
  - 2y ago

skywhopper 2y ago

That’s definitely not the understanding that literally anyone outside the Linux team has for what a CVE is, including the people who came up with them and run the database. Overloading a well-established mechanism of communicating security issues to just be a registry of Linux bugs is an abuse of an important shared resource. Sure “anything could be a security issue” but in practice, most bugs aren’t, and putting meaningless bugs into the international security issue database is just a waste of everyone’s time and energy to make a very stupid point.

kuschku 2y ago
> including the people who came up with them How do you figure that? The original definition of CVE is exactly the same as how Linux approaches it. Sure, in recent years security consultants have been overloading CVE to mean something else, but that's something to fix, not to keep.
- frankjr 2y ago
  Can you post the original definition?
  - vel0city 2y ago
    Common Vulnerabilities and Exposures
    - frankjr 2y ago
      Right but I was hoping for a definition which supports OP's claim that "CVE assignment != security issue".
      - kuschku 2y ago
        Then check out these definitions, from 2000, defined by the CVE editorial board: > The CVE list aspires to describe and name all publicly known facts about computer systems that could allow somebody to violate a reasonable security policy for that system As well as: > Discussions on the Editorial Board mailing list and during the CVE Review meetings indicate that there is no definition for a "vulnerability" that is acceptable to the entire community. At least two different definitions of vulnerability have arisen and been discussed. There appears to be a universally accepted, historically grounded, "core" definition which deals primarily with specific flaws that directly allow some compromise of the system (a "universal" definition). A broader definition includes problems that don't directly allow compromise, but could be an important component of a successful attack, and are a violation of some security policies (a "contingent" definition). > In accordance with the original stated requirements for the CVE, the CVE should remain independent of multiple perspectives. Since the definition of "vulnerability" varies so widely depending on context and policy, the CVE should avoid imposing an overly restrictive perspective on the vulnerability definition itself. Under this definition, any kernel bug that could lead to user-space software acting differently is a CVE. Similarly, all memory management bugs in the kernel justify a CVE, as they could be used as part of an exploit.
        frankjr 2y ago
        > to violate a reasonable security policy for that system > with specific flaws that directly allow some compromise of the system > important component of a successful attack, and are a violation of some security policies All of these are talking about security issues, not "acting differently".
        josefx 2y ago

simiones 2y ago

This is completely false. The CVE website defines these very clearly: > The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities [emphasis mine]. In fact, CVE stands for "Common Vulnerabilities and Exposures", again showing that CVE == security issue. It's of course true that just because your code has an unpatched CVE doesn't automatically mean that your system is vulnerable - other mitigations can be in place to protect it.

kuschku 2y ago
That's the modern definition, which is rewriting history. Let's look at the actual, original definition: > The CVE list aspires to describe and name all publicly known facts about computer systems that could allow somebody to violate a reasonable security policy for that system There's also a decision from the editorial board on this, which said: > Discussions on the Editorial Board mailing list and during the CVE Review meetings indicate that there is no definition for a "vulnerability" that is acceptable to the entire community. At least two different definitions of vulnerability have arisen and been discussed. There appears to be a universally accepted, historically grounded, "core" definition which deals primarily with specific flaws that directly allow some compromise of the system (a "universal" definition). A broader definition includes problems that don't directly allow compromise, but could be an important component of a successful attack, and are a violation of some security policies (a "contingent" definition). > In accordance with the original stated requirements for the CVE, the CVE should remain independent of multiple perspectives. Since the definition of "vulnerability" varies so widely depending on context and policy, the CVE should avoid imposing an overly restrictive perspective on the vulnerability definition itself. For more details, see https://web.archive.org/web/20000526190637fw_/http://www.cve.mitre.org/About_CVE/About/exposures.html https://web.archive.org/web/20000526190637fw_/http://www.cve... and https://web.archive.org/web/20020617142755/http://cve.mitre.org/about/definition.html https://web.archive.org/web/20020617142755/http://cve.mitre.... Under this definition, any kernel bug that could lead to user-space software acting differently is a CVE. Similarly, all memory management bugs in the kernel justify a CVE, as they could be used as part of an exploit.
- 2y ago