Hacker News Reader

Hacker News

Comment by bkallus | Hacker News Reader

Parent Full thread

bkallus

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.

View on HN

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

> No, CVE is not a vulnerability database

"No, Common Vulnerabilities and Exposures is not a vulnerability database."

Yeah, IDK where anyone got that idea.

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.

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.

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?

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.

Thanks for the write up, interesting example! Cheers (and nice find) :-)

I'm not the OP but that sounds like http desync bugs like https://portswigger.net/research/http-desync-attacks-request...

Reply on news.ycombinator.com