4 ms·

The CVE system is all kinds of messed up. We need (at least) - A clear policy from the CNAs that describes exactly which bugs should be assigned CVEs. - A pr

The CVE system is all kinds of messed up. We need (at least) - A clear policy from the CNAs that describes exactly which bugs should be assigned CVEs. - A process by which bogus CVEs can be invalidated, and CVE spammers can be banned from further submissions. - A way to register CVEs for vulnerabilities that span multiple programs. - e.g. an HTTP proxy has a low-risk bug, and an HTTP server has a low-risk bug, but when the proxy and the server are deployed together, the bugs become exploitable. - An appeals process for CVE description updates. - e.g. You would not know from the description that CVE-2023-34188 is trivially exploitable and can reliably lock up vulnerable servers because MITRE refuses to update it.

captainkrtek 3y ago
Not trying to be rude, but do you have an example of the “http server and proxy” case? Seems to me if the server is vulnerable, then a proxy in your situation just makes it easier to exploit?
- bkallus 3y ago
  I do :) Until recently, LiteSpeed parsed Content-Length values using strtoll in the base-0 mode. Thus, by sending Content-Length values prefixed with 0, you can get it to interpret the value in base-8. Most HTTP proxy servers strip leading 0s from Content-Lengths, rendering the bug in LiteSpeed not exploitable. Until recently, HAProxy didn't do this, which made HAProxy + LiteSpeed vulnerable to request smuggling. I put together a PoC demonstrating how this can be used to bypass any HAProxy ACL with default configurations for HAProxy (except the added ACL) and LiteSpeed. Clearly, LiteSpeed is more responsible for this problem than HAProxy, but the bug in LiteSpeed violates HAProxy's security model, not its own.
  - captainkrtek 3y ago
    Thanks for the write up, interesting example! Cheers (and nice find) :-)
- semi 3y ago
  I'm not the OP but that sounds like http desync bugs like https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn https://portswigger.net/research/http-desync-attacks-request...
amluto 3y ago
I think a better approach would be to acknowledge that the CVE system thoroughly conflates two almost orthogonal things: 1. CVE numbers are a way to refer to a (potential) issue. With a CVE number, one can look up an issue in a distro bug tracker or ask support a question or search mailing lists. 2. A CVE number comes with an assessment of whether an issue is real and how bad it is, often in the NVD. From the FAQ [0]: > No, CVE is not a vulnerability database. CVE enables the correlation of vulnerability data across tools, databases, and people. This enables two or more people or tools to refer to a vulnerability and know they are referring to the same issue. So I think that a CVE should probably be rejected if it’s a duplicate, but not just for being a non-issue. But anyone using a CVE as evidence that an issue exists and thinks that NVD is doing a bad job should complain about the NVD, not CVE spam. And people should be extremely cautious about expecting the number of CVEs to mean much. [0] https://www.cve.org/ResourcesSupport/FAQs#pc_introcve_nvd_relationship https://www.cve.org/ResourcesSupport/FAQs#pc_introcve_nvd_re...
- cvccvroomvroom 3y ago
  They're a conflation of multiple lifecycle states: reported, confirmed, disclosed, patch available, and exploit available. Perhaps the simplest way to reduce noise is to have 2 numbering systems: provisional "prepress" PCVE and confirmed CVE.
- paulddraper 3y ago
  > No, CVE is not a vulnerability database "No, Common Vulnerabilities and Exposures is not a vulnerability database." Yeah, IDK where anyone got that idea.
TrueDuality 3y ago
Right now the CVE process doesn't allow unilateral rejection of CVEs by maintainers because they have the opposite incentive. It is in their interest to deny that a vulnerability exists, both because there is a perception that more vulnerabilities discovered means lower quality software, but also because that is extra effort their team needs to handle. It's not ethical but its also not uncommon for companies to not investigate and just deny a bug is real. Sometimes it isn't even an ethical issue but just poorly described by the reporter, or something that seems absolutely implausible to the developers. I don't know what improvements to the current process actually look like but it needs to be able to account for effectively fraud and apathy on both side of the equation.

captainkrtek 3y ago

Not trying to be rude, but do you have an example of the “http server and proxy” case? Seems to me if the server is vulnerable, then a proxy in your situation just makes it easier to exploit?

bkallus 3y ago
I do :) Until recently, LiteSpeed parsed Content-Length values using strtoll in the base-0 mode. Thus, by sending Content-Length values prefixed with 0, you can get it to interpret the value in base-8. Most HTTP proxy servers strip leading 0s from Content-Lengths, rendering the bug in LiteSpeed not exploitable. Until recently, HAProxy didn't do this, which made HAProxy + LiteSpeed vulnerable to request smuggling. I put together a PoC demonstrating how this can be used to bypass any HAProxy ACL with default configurations for HAProxy (except the added ACL) and LiteSpeed. Clearly, LiteSpeed is more responsible for this problem than HAProxy, but the bug in LiteSpeed violates HAProxy's security model, not its own.
- captainkrtek 3y ago
  Thanks for the write up, interesting example! Cheers (and nice find) :-)
semi 3y ago
I'm not the OP but that sounds like http desync bugs like https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn https://portswigger.net/research/http-desync-attacks-request...

amluto 3y ago

I think a better approach would be to acknowledge that the CVE system thoroughly conflates two almost orthogonal things: 1. CVE numbers are a way to refer to a (potential) issue. With a CVE number, one can look up an issue in a distro bug tracker or ask support a question or search mailing lists. 2. A CVE number comes with an assessment of whether an issue is real and how bad it is, often in the NVD. From the FAQ [0]: > No, CVE is not a vulnerability database. CVE enables the correlation of vulnerability data across tools, databases, and people. This enables two or more people or tools to refer to a vulnerability and know they are referring to the same issue. So I think that a CVE should probably be rejected if it’s a duplicate, but not just for being a non-issue. But anyone using a CVE as evidence that an issue exists and thinks that NVD is doing a bad job should complain about the NVD, not CVE spam. And people should be extremely cautious about expecting the number of CVEs to mean much. [0] https://www.cve.org/ResourcesSupport/FAQs#pc_introcve_nvd_relationship https://www.cve.org/ResourcesSupport/FAQs#pc_introcve_nvd_re...

cvccvroomvroom 3y ago
They're a conflation of multiple lifecycle states: reported, confirmed, disclosed, patch available, and exploit available. Perhaps the simplest way to reduce noise is to have 2 numbering systems: provisional "prepress" PCVE and confirmed CVE.
paulddraper 3y ago
> No, CVE is not a vulnerability database "No, Common Vulnerabilities and Exposures is not a vulnerability database." Yeah, IDK where anyone got that idea.

TrueDuality 3y ago

Right now the CVE process doesn't allow unilateral rejection of CVEs by maintainers because they have the opposite incentive. It is in their interest to deny that a vulnerability exists, both because there is a perception that more vulnerabilities discovered means lower quality software, but also because that is extra effort their team needs to handle. It's not ethical but its also not uncommon for companies to not investigate and just deny a bug is real. Sometimes it isn't even an ethical issue but just poorly described by the reporter, or something that seems absolutely implausible to the developers. I don't know what improvements to the current process actually look like but it needs to be able to account for effectively fraud and apathy on both side of the equation.