 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
When is a 9.8 CVSS critical security violation not that big a deal? When its rating doesn’t make a lick of sense.
I don’t know about you, but I pay attention when I hear about a software program getting a Common Vulnerability Scoring System (CVSS) mark of 9.8 on its zero to ten scale. Perhaps I should be more cautious. According to Daniel Stenberg, founder and lead developer of the popular open source command line copy tool cURL for transferring data via URLs, the new CVE, CVE-2020-19909, which gave curl a critical vulnerability rating, is scaremongering and grossly inflates the problem’s severity level.
Stenburg’s right.
First, the bug itself is there was an integer overflow problem in cURL’s –retry-delay command line option. The option determines how long cURL should wait until it retires if the previous transfer failed with a transient error. It accepts values in seconds and then internally converts them to milliseconds by multiplying the value by 1000.
A bug? Yes. A security bug? A show-stopping major security bug? Not so much.
True, integer overflows are often bad news, but usually, that’s when an external attacker can control the memory allocation size. That’s not the case here.
In an analysis of the problem, Stenburg pointed out that the issue had first been spotted on July 27, 2019. It was subsequently patched in cURL 7.66.0, which was released in September 2019.
It is indeed odd that a CVE created in 2023 had a 2020 year designation, And, it references a version of cURL with a bug that has since been fixed.
Stenburg is ticked off. Neither he nor the other cURL programmers know who reported this bug or decided it was so awful. They first knew about it when everyone else did — they read about it in the CVE report, which had been made by the National Vulnerability Database (NVD).
The NVD has a reputation for being a reliable source of information about security issues. Steinburg doesn’t think it’s deserved.
Stenburg said, “It was obvious already before that NVD really does not try very hard to actually understand or figure out the problem they grade.” As he pointed out in an earlier blog post about NVD and curl, NVD “don’t even ask us for help or for clarifications of anything.“ They think they can assess the severity of our problems without knowing curl nor fully understanding the reported issues.”
You might dismiss this as one angry developer taking out his frustrations on the NVD, the CVSS, and CVE systems. But, with such a high CVSS number, other security teams examined the problem and agreed with Stenberg. It’s not that big a deal.
Canonical Ubuntu, for example, stated that since the crash can only happen with the command-line tool, “This CVE is not a security issue.” SUSE won’t go that far, but the European Linux power does note that the potential security problem “is not especially plausible because the overflow only happens if the user was trying to specify that curl should wait weeks (or longer) before trying to recover from a transient error.”
I think it’s pretty darn clear this is not a real security problem, 9.8 or not.
This episode opens up larger questions. These are: Is the current CVE system too easily manipulated? And, is this, in turn, leading to inflated severity scores that do not reflect actual threats?
It’s time we address these issues. We have real security problems that need addressing. Incidents such as this do no one any good.
