My summary: when curl is given a specific range of numbers an integer overflow could result in making requests faster than expected. This is described as a DoS.
This sounds like unexpected behavior, but what turns that into a security flaw?
The input required is sort of bonkers, and what is providing that input? Untrusted users plugging arguments into curl sounds like a security flaw in the “upstream” application.
That and many other are indeed crazy, since the calculation is typically done without an operational context (NVD’s argument is they’d rather play safe when it comes to security issues, so scores are higher where context is lacking).
I would rather prefer NVD contact the vendor, seek clarification, and update the CVSS score (I don’t think this happens).
I would rather prefer NVD contact the vendor, seek clarification, and update the CVSS score (I don’t think this happens).
This would be helpful. What would be even more helpful is if they had some sort of indication that they took this “worst case scenario” route.
It would have been way better to have said “we think this is a 9.8 CVSS score based on extremely incomplete information. See here for our policy in this situation.” It’s almost like a single number with no context isn’t enough bits of information…
With some vulnerabilities, all of the information needed to create CVSS scores may not be available. This typically happens when a vendor announces a vulnerability but declines to provide certain details. In such situations, NVD analysts assign CVSS scores using a worst case approach. Thus, if a vendor provides no details about a vulnerability, NVD will score that vulnerability as a 10.0 (the highest rating).
However, since they always provide a Base score, without factoring in the Temporal or Environmental metrics, it will necessarily be calculated using the “worst case scenario”.
NVD then continues to mention this:
Collaboration with Industry
NVD staff are willing to work with the security community on CVSS impact scoring. If you wish to contribute additional information or corrections regarding the NVD CVSS impact scores, please send email to nvd@nist.gov. We actively work with users that provide us feedback.
Daniel must have contacted them, which is why the CVE now is marked Disputed.
I think you may have misunderstood me. I was saying that that information should be attached to the CVSS number itself. So instead of saying e.g. “this vulnerability is CVSS 9.8” you’d say “this vulnerability is a CVSS 9.8, low-confidence” (low confidence meaning, NVD didn’t have a lot of information to work with). This would help to distinguish from “CVSS 9.8 high-confidence” (NVD did have all the info they needed, which at least somewhat implies that this represents a true threat and not a theoretical worst-case scenario NVD made up).
I will admit though that I didn’t read that link, just the parts you quoted, so maybe I just don’t know enough about CVSS scoring.
Ah, okay. Yes, specifying the confidence level next to the score is definitely useful in effective risk mitigation. I will definitely welcome this change.
It’s definitely a bug since triggering UB is uh… not great. But yeah since the input is given by the person running curl it’s not meaningfully bad and it seems like current compilers don’t turn the UB into a security vulnerability?
Not to even mention that no person or script actually would use such numbers on the command line that trigger the bug. This is the bug that never triggered for anyone who did not deliberately try to make it happen.
I tend to disagree with this thinking. Daniel dismisses the issue is a security hole and then directly asserts no one would even use this feature anyways as if to bolster the argument around it not being a problem or security issue.
To say it’s a buggy feature that no one hits in practice anyways is fine, but it is entirely orthogonal to whether or not this is actually a security issue. If this bug is used as part of a security vulnerability (or within an exploit chain) “they” would deliberately use whatever means they can to trigger UB or buggy behavior to further the exploit.
What you’re saying is exactly the philosophy that leads to CVSS scoring everything “critical”. You can always imagine a scenario where someone would set up themselves for a colossal failure when hitting even a smallest bug.
If you don’t include probability of this happening in your evaluation, you get absurdly inflated danger. You have to consider how unlikely it is that someone would allow attackers to specify the timeout with arbitrarily large numbers, while also critically rely on this timeout to be in a specific range.
Yes, CVSS is entirely ignorant of this dimension. If there is any imaginable deployment scenario in which the vulnerability is triggered by input from the network, you get AV:N (“Attack Vector: Network”, the worst one).
If there is any imaginable scenario where the vulnerability causes severe harm to confidentiality or integrity, you get C:H and I:H - as curl did in this case.
Because you can nearly always come up with very bad scenarios, the most common CVSS by far is exactly 9.8 - everything maxed out except “Attack Complexity: Medium”.
Thus, use-after-free in nginx’ HTTP request parser is a 9.8/10, but so is this total nothingburger in curl. Because in theory you might deploy it in a way where attackers get to control specifically --retry-delay over the network and you might compile it using a hypothetical C compiler that turns integer overflow UB into arbitrary code exec.
For us practitioners, this quickly turns it into a “boy cries wolf” situation. If every CVE is severe, none of them are.
This is why, when I’m writing security announcements, I try to be very descriptive about how the vulnerability might be exploited. That way folks can actually understand how much of a nothingburger the vulnerability actually is. Unfortunately that requires some domain knowledge on the part of the reader, so folks that don’t have that kind of domain knowledge are stuck trying to interpret a number. The whole numbering scheme is very problematic IMO and a source of pain for me personally.
I definitely agree with what you’re saying, so it’s possible I didn’t articulate my thoughts correctly. I 100% agree CVSS scores are often inflated and you have to take into account the likelihood of someone hitting said code path to be a vulnerability.
My point was also not talking about this specific case with curl which I agree is probably a non-issue. I was speaking about a hypothetical scenario in which lets say some program had an argument --foo N where some values of N lead to a real vulnerability for example --foo=999, but in normal use of the program no real users ever set N to that vulnerable value, they all use --foo=3 or --foo=1. I was saying it doesn’t matter that normal users don’t use the vulnerable value, an attacker easily could. So I think in my made up scenario I’m weighing the “ease” at which an attacker could use the vulnerability, and entirely disregarding whether or not a normal user uses the vulnerable values.
But I’ll concede my thinking isn’t really applicable to this case, and thus confused the conversation.
Daniel dismisses the issue is a security hole and then directly asserts no one would even use this feature anyways as if to bolster the argument around it not being a problem or security issue.
I agree that he asserts it’s not a security problem. I would not agree that he asserts it’s not an issue, since it was fixed.
It also is apparent that Daniel spent the time to understand how this would behave in practice, and supplied evidence that it was not a risk in practice.
(down-thread)
you might compile it using a hypothetical C compiler that turns integer overflow UB into arbitrary code exec.
Daniel is direct about the idea of hypothetical/theoretical problems not being sufficient. I do think actual an demonstration is a better place to come from than a hypothetical that then needs to be exhaustively disproven - and it can’t be, the hypothetical space is infinite.
I agree with Daniel here. Unless there exists a C compiler that does turn the UB into arbitrary code exec, there seems no reason to even consider that a real possibility.
It’s just a matter of time before someone creates the world’s worst C compiler which is technically compliant with the standard specifically to win an argument about CVE severity ranking.
People have been joking about the Deathstation 9000 C compiler for like 30 years, but no one has (as far as I know) implemented a compiler that actually uses the most perverse possible interpretation of the standard. Perhaps the closest is the Frama C static anslyser?
And, even if it was arbitrary code exec, I’ve still seen zero examples of a realistic scenario where an attacker would be able to control this parameter without having arbitrary code exec anyway.
The problem with relying on UB to escalate severity is that it’s not possible to write a non-trivial C program that’s completely free of UB, at which point everything just escalates automatically to max severity because there’s probably a code path that hits UB.
My summary: when curl is given a specific range of numbers an integer overflow could result in making requests faster than expected. This is described as a DoS.
This sounds like unexpected behavior, but what turns that into a security flaw?
The input required is sort of bonkers, and what is providing that input? Untrusted users plugging arguments into curl sounds like a security flaw in the “upstream” application.
Regardless, that severity is crazy.
That and many other are indeed crazy, since the calculation is typically done without an operational context (NVD’s argument is they’d rather play safe when it comes to security issues, so scores are higher where context is lacking).
I would rather prefer NVD contact the vendor, seek clarification, and update the CVSS score (I don’t think this happens).
This would be helpful. What would be even more helpful is if they had some sort of indication that they took this “worst case scenario” route.
It would have been way better to have said “we think this is a 9.8 CVSS score based on extremely incomplete information. See here for our policy in this situation.” It’s almost like a single number with no context isn’t enough bits of information…
They actually do, see https://nvd.nist.gov/vuln-metrics/cvss (relevant part reproduced below):
However, since they always provide a Base score, without factoring in the Temporal or Environmental metrics, it will necessarily be calculated using the “worst case scenario”.
NVD then continues to mention this:
Daniel must have contacted them, which is why the CVE now is marked Disputed.
I think you may have misunderstood me. I was saying that that information should be attached to the CVSS number itself. So instead of saying e.g. “this vulnerability is CVSS 9.8” you’d say “this vulnerability is a CVSS 9.8, low-confidence” (low confidence meaning, NVD didn’t have a lot of information to work with). This would help to distinguish from “CVSS 9.8 high-confidence” (NVD did have all the info they needed, which at least somewhat implies that this represents a true threat and not a theoretical worst-case scenario NVD made up).
I will admit though that I didn’t read that link, just the parts you quoted, so maybe I just don’t know enough about CVSS scoring.
Ah, okay. Yes, specifying the confidence level next to the score is definitely useful in effective risk mitigation. I will definitely welcome this change.
It’s definitely a bug since triggering UB is uh… not great. But yeah since the input is given by the person running curl it’s not meaningfully bad and it seems like current compilers don’t turn the UB into a security vulnerability?
I tend to disagree with this thinking. Daniel dismisses the issue is a security hole and then directly asserts no one would even use this feature anyways as if to bolster the argument around it not being a problem or security issue.
To say it’s a buggy feature that no one hits in practice anyways is fine, but it is entirely orthogonal to whether or not this is actually a security issue. If this bug is used as part of a security vulnerability (or within an exploit chain) “they” would deliberately use whatever means they can to trigger UB or buggy behavior to further the exploit.
What you’re saying is exactly the philosophy that leads to CVSS scoring everything “critical”. You can always imagine a scenario where someone would set up themselves for a colossal failure when hitting even a smallest bug.
If you don’t include probability of this happening in your evaluation, you get absurdly inflated danger. You have to consider how unlikely it is that someone would allow attackers to specify the timeout with arbitrarily large numbers, while also critically rely on this timeout to be in a specific range.
Yes, CVSS is entirely ignorant of this dimension. If there is any imaginable deployment scenario in which the vulnerability is triggered by input from the network, you get AV:N (“Attack Vector: Network”, the worst one). If there is any imaginable scenario where the vulnerability causes severe harm to confidentiality or integrity, you get C:H and I:H - as curl did in this case.
Because you can nearly always come up with very bad scenarios, the most common CVSS by far is exactly 9.8 - everything maxed out except “Attack Complexity: Medium”. Thus, use-after-free in nginx’ HTTP request parser is a 9.8/10, but so is this total nothingburger in curl. Because in theory you might deploy it in a way where attackers get to control specifically
--retry-delayover the network and you might compile it using a hypothetical C compiler that turns integer overflow UB into arbitrary code exec.For us practitioners, this quickly turns it into a “boy cries wolf” situation. If every CVE is severe, none of them are.
This is why, when I’m writing security announcements, I try to be very descriptive about how the vulnerability might be exploited. That way folks can actually understand how much of a nothingburger the vulnerability actually is. Unfortunately that requires some domain knowledge on the part of the reader, so folks that don’t have that kind of domain knowledge are stuck trying to interpret a number. The whole numbering scheme is very problematic IMO and a source of pain for me personally.
I definitely agree with what you’re saying, so it’s possible I didn’t articulate my thoughts correctly. I 100% agree CVSS scores are often inflated and you have to take into account the likelihood of someone hitting said code path to be a vulnerability.
My point was also not talking about this specific case with curl which I agree is probably a non-issue. I was speaking about a hypothetical scenario in which lets say some program had an argument
--foo Nwhere some values ofNlead to a real vulnerability for example--foo=999, but in normal use of the program no real users ever setNto that vulnerable value, they all use--foo=3or--foo=1. I was saying it doesn’t matter that normal users don’t use the vulnerable value, an attacker easily could. So I think in my made up scenario I’m weighing the “ease” at which an attacker could use the vulnerability, and entirely disregarding whether or not a normal user uses the vulnerable values.But I’ll concede my thinking isn’t really applicable to this case, and thus confused the conversation.
I agree that he asserts it’s not a security problem. I would not agree that he asserts it’s not an issue, since it was fixed.
It also is apparent that Daniel spent the time to understand how this would behave in practice, and supplied evidence that it was not a risk in practice.
(down-thread)
Daniel is direct about the idea of hypothetical/theoretical problems not being sufficient. I do think actual an demonstration is a better place to come from than a hypothetical that then needs to be exhaustively disproven - and it can’t be, the hypothetical space is infinite.
I agree with Daniel here. Unless there exists a C compiler that does turn the UB into arbitrary code exec, there seems no reason to even consider that a real possibility.
It’s just a matter of time before someone creates the world’s worst C compiler which is technically compliant with the standard specifically to win an argument about CVE severity ranking.
People have been joking about the Deathstation 9000 C compiler for like 30 years, but no one has (as far as I know) implemented a compiler that actually uses the most perverse possible interpretation of the standard. Perhaps the closest is the Frama C static anslyser?
Haha yes, I am sure someone will be crazy enough to do this. Especially now that our discussion is public! :-)
Shouldn’t be that hard to change ubsan from reporting issues to execve(some_suid_binary) instead…
And, even if it was arbitrary code exec, I’ve still seen zero examples of a realistic scenario where an attacker would be able to control this parameter without having arbitrary code exec anyway.
The problem with relying on UB to escalate severity is that it’s not possible to write a non-trivial C program that’s completely free of UB, at which point everything just escalates automatically to max severity because there’s probably a code path that hits UB.