The Bogus CVE Problem

Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

By Jake Edge
September 13, 2023

The "Common Vulnerabilities and Exposures" (CVE) system was launched late in the previous century (September 1999) to track vulnerabilities in software. Over the years since, it has had a somewhat checkered reputation, along with some some attempts to replace it, but CVE numbers are still the only effective way to track vulnerabilities. While that can certainly be useful, the CVE-assignment (and severity scoring) process is not without its problems. The prominence of CVE numbers, and the consequent increase in "reputation" for a reporter, have combined to create a system that can be—and is—actively gamed. Meanwhile, the organizations that oversee the system are ultimately not doing a particularly stellar job.

A recent incident highlights some of the problems inherent in the system. CVE-2020-19909, which is an integer-overflow bug in the curl tool and library for URL-based data transfers that was only reported to the project in 2023. In a blog post describing the mess, curl maintainer Daniel Stenberg said that a message to the curl-library mailing list on August 25 alerted the project that the CVE had become public the week before.

The year in the CVE number (2020 in this case) is meant to indicate when the bug was reported to one of the more than 300 CVE numbering authorities (CNAs) that hand out CVE numbers. Under normal circumstances, a new bug showing up with a CVE number would have 2023 in it, but sometimes CVEs are given out for older bugs that somehow slipped through the cracks. That appears to be what happened in this case, as Stenberg was able to track the problem back to a bug report from Jason Lee in mid-2019.

The report was for a legitimate bug, where the ‑‑retry‑delay option value was being multiplied by 1000 (to milliseconds) without an overflow check. But what it was not was a security bug, Stenberg said; giving insanely large values for the option might result in incorrect delays—far shorter than requested—but it is not a security problem to make multiple requests in a short time span. If it were, "then a browser makes a DOS [denial of service] every time you visit a website — and curl does it when you give it two URLs on the same command line", he said in a followup post.

The problem was duly fixed, a test case was added, and Lee was credited with the report in the commit message. In September 2019, curl 7.66.0 was released with fix, which was mentioned in the announcement; also notable are the two CVEs mentioned at the top of the bug fixes listed. As Stenberg noted, the curl project works hard to ensure that it fully documents the (real) CVEs that get filed for it; his exasperation with CVE-2020-19909 coming out of the blue is evident:

In the curl project we work hard and fierce on security and we always work with security researchers who report problems. We file our own CVEs, we document them and we make sure to tell the world about them. We list over 140 of them with every imaginable detail about them provided. We aim at providing gold-level documentation for everything and that includes our past security vulnerabilities.

That someone else suddenly has submitted a CVE for curl is a surprise. We have not been told about this and we would really have liked to. [...]

The National Vulnerability Database (NVD) tracks CVEs and "scores" them using the Common Vulnerability Scoring System (CVSS), which is a ten-point scale that is meant to give an indication of the severity of a vulnerability. For the curl bug, which should probably not be scored at all, NVD initially came up with a "9.8 critical", scoring an integer overflow in a delay parameter as one of the most severe types of vulnerability possible. Stenberg, who has tangled with NVD over scoring before, is even further exasperated:

It was obvious already before that NVD really does not try very hard to actually understand or figure out the problem they grade. In this case it is quite impossible for me to understand how they could come up with this severity level. It's like they saw "integer overflow" and figure that wow, yeah that is the most horrible flaw we can imagine, but clearly nobody at NVD engaged their brains nor looked at the "vulnerable" code or the patch that fixed the bug. Anyone that looks can see that this is not a security problem.

In fact, the pull request for the fix was attached to the report, but that apparently made little difference in the assessment from NVD. Back in March, Stenberg decried the NVD scoring process and, in particular, the NVD practice of re-scoring CVEs that have already had severity levels attached to them. NVD uses CVSS, but the curl project long ago rejected that scoring system:

In the curl project we decided to abandon CVSS years ago because of its inherent problems. Instead we use only the four severity names: Low, Medium, High, and Critical and we work out the severity together in the curl security team as we work on the vulnerability. We make sure we understand the problem, the risks, its prevalence and more. We take all factors into account and then we set a severity level we think helps the world understand it.

His example in that case is a double-free in curl that the project determined had a "medium" severity, while NVD scored it as "9.8 critical", as can be seen in the GitHub advisory database. Since then, NVD apparently had a change of heart after Stenberg's complaint as the CVE is now scored "8.1 high". In a followup on NVD "brokenness", Stenberg gave another example of a CVE that was initially scored "9.8 critical", but eventually was reduced to "5.9 medium" after complaints—though the curl project rates it as "low". He also noted that there is a set of projects that never report low or medium CVEs that they find, in order to avoid these kinds of scoring woes.

One could perhaps wonder if this is all just a problem for the curl project and not more widespread, but there is a fair amount of evidence of a variety of problems in CVE-land. For example, the PostgreSQL project had a similar problem with a CVE "from" 2020 that appeared recently—and is not a security vulnerability at all, according to the project. In June, the KeePassXC password manager project had a bogus CVE filed for the tool; there are other examples as well.

Each of these bogus CVE filings, which can apparently be made anonymously and without much in the way of backing information, require that the project notice its existence, analyze the problem (or "problem"), and, if necessary, dispute the existence or score of the CVE. As noted, several curl CVEs have had their scores reduced rather substantially due to requests from the project. The delay parameter overflow that was initially scored 9.8 has been reduced to "3.3 low", marked as "disputed", and had a link to Stenberg's blog post added to the NVD entry.

Keeping up with all of that is a lot of work, which Stenberg said he is going to try to avoid in the future by applying to become the CNA for curl. Several other open-source projects are CNAs, which gives them some notification of a reported problem along with ways to try to ensure that the problem is handled sanely. He mentioned Apache, OpenSSL, and Python as some of the projects that are already CNAs; Python was just granted CNA status at the end of August.

Meanwhile, though, CVEs are used in ways that elevate their importance well beyond the level that makes sense given the amount of scrutiny that is apparently applied to them. Service-level contracts and governmental requirements mean that a critical CVE needs to be addressed in short order, so non-critical bugs that get marked that way can cause real problems. It does provide incentives for companies and others to try to downplay the severity of bugs, as well, of course, which makes for something of a "Pushmi-Pullyu" in CVE-land.

As was alluded to in our mid-August look at kernel security reporting for distributions, the CVE system is generally included in the "security circus" that kernel developers largely disdain. A 2019 talk by Greg Kroah-Hartman described multiple problems that he sees with the system as well.

All in all, the CVE system seems to be broken in various ways. It also seems to be getting more and more entrenched into "cybersecurity" handling at various levels. Given that it is effectively run by—and now for—governmental agencies, the ability to replace it with something more sensible has likely already passed us by. CVE, warts and all, will be with us for a long time to come; FOSS projects and organizations are simply going to have to figure out how to coexist with it.

---

(Log in to post comments)

from Hacker News https://ift.tt/hatdcXD