)
While scrolling through my infosec feed, I came across an article titled CVE-2020-19909 is Everything that’s Wrong with CVEs, which was written by Daniel Stenberg, a Swedish developer. Since 1996, Stenberg has authored and has maintained cURL, an extremely popular open-source tool that allows users to get or send data via a URL syntax.
In this article, Stenberg explains that the National Vulnerability Database (NVD) just assigned a new CVE designation, CVE-2020-19909, for an integer overflow vulnerability in cURL, and scored it as 9.8 - critical.
This issue affects how long cURL should wait until it makes a retry if the previous transfer failed. Stenberg asserts that it was originally disclosed in 2020 (hence the year 2020 despite the CVE’s release in 2023), and that this was a bug that was promptly patched. Defiantly, he argues that “anyone that looks can see that this is not a security problem,” and accuses the NVD of gross inflation of the criticality that causes scaremongering.
In a minor win for Stenberg and cURL, the NVD’s site now lists its designation for CVE-2020-19909 as disputed, notes that it is awaiting reanalysis, and links to Stenberg’s blog. However, this episode raises three questions:
Why did this happen?
The CVSS base scores are determined by an algorithmic calculator. Every vulnerability includes a “Vector,” which explains exactly what inputs the calculator took to generate the score.
If we enter these inputs into the calculator, we can indeed see that the resulting score is 9.8.
Looking closer, the “Exploitability Metrics” make sense: cURL is a tool used over the network. Attack complexity is low, since this method can be repeated. It requires no privileges nor for a remote user to perform an action, and it doesn’t affect anything beyond the targeted resource.
However, the “Impact Metrics” are indeed puzzling. It is very unclear how this integer overflow issue can affect confidentiality, integrity, or availability. If it cannot, as Stenberg asserts, then the CVSS score should be 0.0. The burden of proof to demonstrate otherwise ought to be on the vulnerability’s reporter or the NVD, however, in our understanding, no proof-of-concept exists.
Why should we care?
Stenberg’s fierce disputation is not without merit. When the NVD designates a critical remote code execution vulnerability in a tool used by countless enterprises, it sets off alarm bells in security teams around the world as they frantically fear that this might be another Log4j. If organizations invest resources in dealing with something that doesn’t matter, it will come at the expense of dealing with something that does.
Meanwhile, it puts cURL’s team on the defensive, forcing them to defend their product’s integrity and deal with a wave of unwarranted publicity. While many vendors have been negligent about patching vulnerabilities in their products, the ones that did nothing wrong should not be guilted.
Is there a better way to score CVEs?
cURL’s documentation bluntly accuses the CVE of being “filed and made public by an anonymous person due to incompetence or malice. We cannot say which and the distinction does not matter to us.”
Even if we give the benefit of the doubt, this episode shows how a few individuals might mistakenly enter the wrong input into the CVSS calculator and issue a CVE that causes hysteria. The CVSS score, simply put, is generated by a small number of people choosing from a small number of variables.
Instead, a true scoring of a CVE should draw from the entire ecosystem of activity. Is there a Metasploit module with an exploit? Are there POC exploits on Github, and how many people are watching them? Is there chatter about exploits on underground forums? Are APTs and ransomware groups using this vulnerability in their attacks?
In Cybersixgill’s Dynamic Vulnerability Exploit (DVE) Intelligence, we take all of these factors into account to generate a score that is more reflective of the true risk. Indeed, the purely speculative nature of this vulnerability, without any concrete demonstration of its security impact, earned it a paltry score of 0.18. However, our score is dynamic; if the ecosystem changes, so will the score.
CVE-2020-19909 is hardly worth asking your CISO about. But who knows how many other CVSS scores were inadequately assigned? And who can measure how many organizational resources have been misappropriated due to inappropriate CVSS scores?
Get started with DVE Intelligence – request a demo.
)
)
)
)