When a security vulnerability has been found and confirmed in curl, we request a CVE Id for the issue. This is a global unique identifier for this specific problem. We request the ID from our CVE Numbering Authority (CNA), Hackerone, which once we make the issue public will publish all details about it to MITRE, which hosts the central database.
In the curl project we have until today requested CVE Ids for and provided information about 135 vulnerabilities spread out over twenty-five years.
A CVE identifier affects a specific product (or set of products), and the problem affects the product from a version until a fixed version. And then there is a severity. How bad is the problem?
CVSS score
The Common Vulnerability Scoring System (CVSS) is a way to grade severity on a scale from zero to ten. You typically use a CVSS calculator, fill in the info as good as you can and voilá, out comes a score.
The ranges have corresponding names:
| Name | Range |
| Low | lower 4 |
| Medium | 4.0-6.9 |
| High | 7.0-8.9 |
| Critical | 9 or higher |
CVSS is a shitty system
Anyone who ever gets a problem reported for their project and tries to assess and set a CVSS score will immediately realize what an imperfect, simplified and one-dimensional concept this is.
The CVSS score leaves out several very important factors like how widespread the affected platform is, how common the affected configuration is and yet it is still very subjective as you need to assess as and mark different things as None, Low, Medium or High.
The same bug is therefore likely to end up with different CVSS scores depending on who fills in the form – even when the persons are familiar with the product and the error in question.
curl severity
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.
All security vulnerabilities are vulnerabilities and therefore security risks, even the ones set to severity Low, but having the correct severity is still important in messaging and for the rest of the world to get a better picture of how serious the issue is. Getting the right severity is important.
NVD
Let me introduce yet another player in this game. The National Vulnerability Database (NVD). (And no, it’s not “national” really).
NVD hosts a database of vulnerabilities. All CVEs that are submitted to MITRE are sucked in into NVD’s database. NVD says it “performs analysis on CVEs that have been published to the CVE Dictionary“.
That last sentence is probably important.
NVD imports CVEs into their database and they in turn offer other databases to import vulnerabilities from them. One large and known user of the NVD database is this I mentioned in a recent blog post: GitHub Security Advisory Database (GHSA DB) .
GHSA DB
This GitHub thing an ambitious database that subsequently hosts a lot of vulnerabilities that people and projects reported themselves in addition to them importing information about all vulnerabilities ever published with CVE Ids.
This creates a huge database that in theory should contain just about every software vulnerability ever reported in the public. Pretty cool.
Enter reality
NVD, in their great wisdom, rescores the CVSS score for CVE Ids they import into their database! (It’s not clear how or why, but they seem to not do it for all issues).
NVD decides they know better than the project that set the severity level for the issue, enters their own answers in the CVSS calculator and eventually sets that new score on the CVEs they import.
NVD clearly thinks they need to do this and that they improve the state of the CVEs by this practice, but the end result is close to scaremongering.
Result
Because NVD sets their own severity level and they have some sort of “worst case” approach, virtually all issues that NVD sets severity for is graded worse or much worse when they do it than how we set the severity levels.
Let’s take an example: CVE-2022-42915: HTTP proxy double-free. We deemed this a medium severity. It was not made higher partly because of the very limited time-window between the two frees, making it harder to take advantage of.
What did NVD say? Severity 9.8: critical. See the same issue on GitHub.
Yes, it makes you wonder what magic insights and knowledge the person/bots on NVD possessed when they did this.
Scaremongering
The different severity levels should not matter too much but people find those inflated ones and they believe them. Users also find the discrepancies, get confused and won’t know what to believe or whom to trust. After all, NVD is trust-inducing brand. People think they know their stuff and if they say critical and the curl project says medium, what are we expected to think?
I claim that NVD overstate their severity levels and there unnecessarily scares readers and make them think issues are worse and more dangerous than they actually are.
The fact that GitHub now imports all CVE data from NVD makes these severity levels get transported, shown and believed as they are now also shown in the GHSA DB.
Look how many critical issues there are!
Not exactly GitHub’s fault
This NVD habit of re-scoring is an old existing habit and I just recently learned it. GitHub’s displaying the severity levels highlighted it for me, especially since users out there seem to trust and use this GitHub database.
I have talked to humans on the GitHub database team and I push for them to ignore or filter out the severity levels as set by NVD, if possible. But me being just a single complaining maintainer I do not expect this to have much of an effect. I would urge NVD to stop this insanity if I had any way to.
Hackerone glitches?
(Updated after first post). It turns out that some CVEs that we have filed from the curl project that uses our CNA hackerone have been submitted to MITRE without any severity level or CVSS score at all. For such issues, I of course understand why someone would put their own score on the issue because then our originally set score/severity is not passed on. Then the “blame” is instead shifted to Hackerone. I have contacted them about it.
Dispute a CVSS
NVD provides a way to dispute their rescores, but that’s just an open free-text form. I have use that form to request that NVD stop rescoring all curl issues. Although I honestly think they should rather stop all rescoring and only do that in the rare occasions where the original score or severity is obviously wrong.
I cannot dispute the severity levels at GitHub. They show the NVD levels.
So the NVD CVE/CVSS scoring basically boils down to:
1) Things the US government really cares about, that’s what they put effort into assigning a CVSS score to
2) The NVD takes a worst severity approach, especially if it’s “unknown”, e.g. “remote or local? if unknown pick remote”
3) The NVD also takes a worst case using it approach, e.g. “Samba? We’re going to assume it might be exposed to the full Internet” when most vendors explicitly say “do not expose Samba to the Internet, just use it locally” for example.
And thus the CVSS ratings from NVD are much higher than what one would typically expect.
So this is an ongoing issue in the vulnerability identifier ecosystem, and especially with respect to CVE/NVD, and one of the reasons the GSD exists. The GSD allows namespaced data, so multiple people can speak their truth (e.g. for a curl vuln from CVE we have the cve.org and the nvd.nist.gov data), and in this case, this leads to a feature we should probably add to allow a project to override these values with their own, more authoritative ones. I’ve started a discussion at https://github.com/cloudsecurityalliance/gsd-tools/discussions/151 if anyone wants to weigh in.
That’s a uniquely NVD issue though. MITRE, and CVE, don’t provide CVSS scores.
It’s also worth noting that NVD, like most that use CVSS, use it wrong. There’s a particular onus on the user who decides to use CVSS to use it properly.
>I have use that form to request that NVD stop rescoring all curl issues.
Did it work? Have they stopped?
NVD accepts some external CVSS scores: https://nvd.nist.gov/vuln/cvmap
In my experience, NVD scores CVSS very “correctly.” But this is separate from the design or value or use of CVSS. Anchoring on or arguing about CVSS Base scores and boundaries may not be good use of your time. Not following my own advice, for CVE-2022-42915, it seems like either a malicious proxy or URL is required, plus a timing constraint, so AC:H and possibly UI:Y.
CVSS is optional for CVE, some CVE records contain CVSS scores, these are often re-evalutated by NVD.
NVD also re-evaluates or adds CWE: https://nvd.nist.gov/vuln/categories
NVD has a not-widely-used Vendor Comment feature: https://nvd.nist.gov/vuln/vendor-comments