Hard to imagine how that could lead to any security compromise, the seemingly randomly assigned criticality is certainly unpleasant. Could it be that it was detected by "automated source code" and "website vulnerability" reports, when the tools very often assign HIGH, CRITICAL to random issues that aren't the problems
I'd say it's more like a manifestation of the neurology of humans: we are very bad at catching rare occurrences in stream of repeated events. Unless they somehow stand out from the rest, our brains aren't wired to notice them.
Even if it is really reviewed it is reviewed by somebody who is part of the recent (5 years or so?) explosion of “cybersecurity” and thus incentived to overblow the issue.
It's reviewed by someone without any knowledge on the exploitable software. And even if it wouldn't take hours to even set up a testing environment, most CVEs don't include enough information to build an exploit anyway. No need to assume that the reviewers overblow these issues deliberately, there simply isn't anything to meaningfully review in most cases. They can filter out obviously meaningless bullshit, but that's about it.
Source: Found a handfull of RCEs for popular PHP projects, some of which have CVEs.
I had a QA coworker who got some online certification and was able to jump into a full remote cybersecurity role at our company with a large pay increase. I’ve worked with her for nearly a decade and while she is pretty good at QA I would never have really seen her as cybersecurity material. Now you say there has been an explosion in this area and I wondering if they are taking any warm body.
Elephant in the room is if this person was let go by ChatGPT … because if you ask chatGPT … it says this is serious - likely because of the word integer overflow in the description.
Yes, and there are cognitive and neurological reasons why that cannot work.
"the story of AI being managed by a "human in the loop" is a fantasy, because humans are neurologically incapable of maintaining vigilance in watching for rare occurrences."
> Hard to imagine how that could lead to any security compromise
Integer overflows as a vulnerability class are often very bad, but usually when they're describing an attacker-controlled memory allocation size (which the attacker's buffer will then go on to overflow, often to byte-specific length accuracy). Sounds like the reviewer here could have been someone primed to think that "integer overflow" meant "integer overflow controlling a memory allocation", which doesn't seem to be the case here at all.
@dang Title filtering may have stripped out the CVE number, which is important context in the original title: "CVE-2020-19909 is everything that is wrong with CVEs"
As far as I know, there's no "CVE grading people". The submitter of the CVE decides on the severity. You probably can appeal to MITRE folks if it's hilariously inaccurate but I think that's how it mostly works.
I keep getting emails from India-based "ethical hackers" who ran a vulnerability assessment against some web property and sent me the results. Then they ask for payment. I keep reporting them to Google (Gmail IDs) but they keep landing in my inbox.
I think it has to have an "or else" to be extortion. If its just, consider giving us a gift if you found this report useful, that doesn't sound like extortion (still obnoxious though)
They typically do not want to disclose the full vulnerability details prior to you paying them.
For the few that we have engaged in back and forth conversation, they typically were just reporting warnings from various opensource website scanners, without completely understanding what they were talking about.
That's not to say somebody might discover a new unique vulnerability in the open source software and packages you might be using, except you wouldn't expect them to report it to your company, as some random user on the Internet, when the official projects are on github.
Alternatively if they reported a very specific issue regarding software you developed, I'm sure it would get your 100% attention. That's not been my experience so far (knock on wood).
Yeah if they are refusing to share details without money that sounds more like extortion.
> That's not to say somebody might discover a new unique vulnerability in the open source software and packages you might be using, except you wouldn't expect them to report it to your company, as some random user on the Internet, when the official projects are on github.
I've actually had this happen once or twice. AFAICT the situation was either that the reporter explains themselves so poorly (in very broken english) that the original project ignored them, or they are trying to maximize bounties by reporting to everyobe who uses the package instead of the actual maintainer.
> Alternatively if they reported a very specific issue regarding software you developed, I'm sure it would get your 100% attention. That's not been my experience so far (knock on wood).
It does happen (especially if you offer bounties or you are famous), but its like 1% of emails you get at most. Most reports are just incoherent non sense or people misunderstanding the output of an autonated scanner. But its worth it to pay attention for the 1%.
It's always worded as though you have some trivially exploited RCE, unless you pay them, someone will exploit it. To be fair I'm not suggesting they imply that they will exploit it, but it's always overblown in a way that implies without paying to see their nonsense report your business will suffer a loss.
It's more like panhandling. They don't have anything to threaten with, the most they have is some minor complaint on a test scan, like Apache version being reported by some server, so they just try to score some money for nothing.
I mean, im not sure what you expect google to do. Its not illegal to send bad security report emails, and i wouldn't exactly call it spam in the traditional sense.
They are annoying though. I'm pretty sure 90% of the value proposition of hackerone is dealing with these people.
I've reviewed hundreds of security reports over the last ten years. I have yet to see a legitimate one. This is good (no security bugs!) but also a massive waste of time, because I do need to review them because what if there is an actual serious report?
Is it "spam" in the sense of Nigerian princes and penis enlargements? No. Is it "spam" in the sense that it's the same useless crap being repeated ad nauseam? Absolutely.
Yup, HackerOne has more or less created a cottage industry of "hackers" that file HackerOne bug reports using semi-automated tools like Burp Suite etc. to get bounties.
It's not unique to India, they are everywhere. The best thing is just ignore them, usually once they are sure there's no money to be made here, they move on quickly.
9.8 sounds more like an easily exploitable RCE than what is IMHO barely even worthy of being called a bug. But as long as there is incentive for the security industry to inflate their accomplishments, they will.
Working for a company that requires triaging critical vulnerabilities within a few days I’ll attest to how many “critical” that are mostly unexploitable due to a variety of reasons. There has to be a better way.
I’ve also had zealots want to introduce some pretty significant nonsense to CI for these. I enjoyed when that meant the CTO began getting emails about my products having critical vulnerabilities. Except, uh, we don’t ever use a single Django template and whatnot.
I don't think summarizing the criticality of a vulnerability as a single number is possible. Many vulnerabilities really are critical, but only to some users of a software that have some feature enabled (that might be disabled by default). The best way to communicate the criticality of a vulnerability is in text.
The worst is when some build tool has a bad regex backtracking implementation leading to denial of service with bad patterns.
Of course the right answer is to just keep upgrading our dependencies... so our build machine doesn't fall into an infinite loop when a hacker rewrites our build scripts?
I've seen a bit of discussion lately about EPSS[0], which is a model that tries to take more practical metrics about any given CVE (including pieces of the CVSS, but also things like whether there's a GitHub PoC or if it's up on ExploitDB) and return a real-world exploitability score out of 100.
I can't help but imagine something like this is where we're headed, given how counterproductive it can be to make decisions based on CVSS scores...
The problem is that a measure became a target. Most companies with a significant internet presence and a "cybersecurity" division have a policy of patching all CVEs. They can't understand vulnerabilities, there are too many and it's too hard, so the policy is to buy products that scan for software versions with known CVEs, and require other teams to patch/upgrade them. This is how most of the industry works now.
So of course there is now huge motivation to get these CVE things, inflate them, never under-grade them, just in case ... so of course CVEs are becoming more noisy and useless, and many orgs (including my company) are now moving to EPSS. Just give it a few years though, this EPSS will probably degrade just like CVE as it becomes widely embedded in enterprise security processes.
Yeah that chimes with my experience. "Cybersecurity" (a name I hate by the way) without threat modelling and analyzing trade-offs is just compliance. There is a lot of bike shedding, cargo cults and general bs "box checking" work. So many players selling "AI" and visuals in the form of overly complicated "scanning" and CVE database querying, which is little more than checking and matching versions, or circular metadata writing and reading. I got in and out of the field in about a year.
+1 I worked in sec analytics and it was just a bunch of ppl sending me excels with cves and devices. Not to mention the team on the other side of the company that deems something critical so now we have multiple tools scanning, feeding garbage data and a bunch of operations folks patching…only to rinse and repeat.
Unfortunately, in C, signed overflow is undefined behavior. Anything can happen, and you should not assume that it is just benign behavior like wraparound. Undefined behavior, in a seemingly unrelated area, can result in a security issue somewhere else in the program thanks to how C deals with undefined behavior.
While I don’t think it is as severe as the CVE indicated, something that triggers undefined behavior in C is not to be dismissed as lightly as the article is doing.
So anything that is undefined on paper automatically gets a near maximum score? That doesn't seem right.
I'm aware there are cases of overzealous compilers removing conditional code based on the incorrect assumption that overflows can never happen, but this doesn't seem to be the case here.
You are technically correct, but signed integer overflows are so pervasive in C that compilers only exploit them when ignoring them would be truly beneficial.
In the case of LLVM for example signed integer overflows will merely produce a poison value, and won't produce the actual UB if it is either optimized out or only used by instructions that can't produce UBs by themselves [1].
Compilers also tend to use the UB as an excuse to optimize things, not to break things. We only care about the UB because a faulty optimization still can cause breakages. In this particular case the poison value will eventually reach the following condition [2]:
/* if retry-max-time is non-zero, make sure we haven't exceeded the
time */
if(per->retry_numretries &&
(!config->retry_maxtime ||
(tvdiff(tvnow(), per->retrystart) <
config->retry_maxtime*1000L)) ) {
So let's assume that `config->retry_maxtime * 1000L` was indeed always a poison value---what can reasonable optimizing compilers do? At worst they will probably evaluate the entire condition as false, because it would help the dead code elimination. Compilers can put a nasal demon in that case, but reasonable ones wouldn't. And since `config->retry_maxtime * 1000L` is not guaranteed to be a poison value all the time, this optimization is not even actually possible. The practical effect of this security bug is quite limited.
> The practical effect of this security bug is quite limited.
You are probably correct (although it's hard to say for sure that you've considered every single compiler optimization).
But even if you are correct, the point of the parent poster still stands:
> something that triggers undefined behavior in C is not to be dismissed as lightly as the article is doing.
I agree with this.
Notice how long your explanation was. The author of the article did not provide a similar explanation, or even an abbreviated one, in order to justify the claims that the bug does not have security implications. In fact, the author didn't even have to provide such an explanation, but he could have at least acknowledged the possibility, which could then be argued to be dismissable based on his (extensive) experience.
I'm not saying that there are security implications or that the burden of proving that there aren't any is on the author of the article.
I'm only agreeing with the parent poster that you cannot easily or simply claim that the bug is not a security vulnerability, without giving some consideration to the possible impact of UB, or at least acknowledging the possibility.
Not acknowledging this possible impact can in fact reinforce misconceptions about the security implications of bugs in C code that lead to UB.
> The author of the article did not provide a similar explanation, or even an abbreviated one, in order to justify the claims that the bug does not have security implications.
Curl already runs ubsan and fuzzer in its testing process [1]. They know what they are doing (you may disagree on the first principles of writing curl in C/C++, but it's not like that curl is not sufficiently aware of UBs), so you should have asked instead why this particular bug was not caught already.
I believe the answer is that this bug occurred in the curl's CLI interface (src/tool_*.c), not in libcurl. The current fuzzer only runs against libcurl so this bug could have slipped in. But then it is even more clear that this bug can't be that serious, because libcurl does all the heavy lifting! Integer overflows themselves are not significant, they have to be paired with other mechanisms to be actually vulnerable (and Rust also agrees, whether overflow checks are enabled or not does not affect the memory safety).
Unless reporters have figured out an ingenious way to exploit a single integer overflow, the OP's reaction is completely justified.
> Integer overflows themselves are not significant, they have to be paired with other mechanisms to be actually vulnerable
No, that is not true. That's a misconception. Your sentence is true for unsigned integer overflows, but not for signed integer overflows, which are undefined behavior in C.
Compilers assume that signed overflows are not possible. They exploit that assumption to perform many significant and important code optimizations, which greatly improve performance. Those optimizations can cause the program behavior to change dramatically in the case that a signed overflow would happen.
In some cases, the compiled code behaves in ways that have nothing to do with how the program was written.
In extreme (but real, documented) cases it can have effects like:
1. Security vulnerabilities being introduced in the compiled code, even though the source code appears to be perfectly safe.
2. Code that isn't called anywhere to be called.
3. The program crashing even though the code looks completely safe, and in fact would have been perfectly safe if the optimizations hadn't been performed.
4. And many more.
These are not theoretical or hypothetical effects. They are real effects that have been demonstrated in real code compiled with widely used compilers (GCC and clang), in some cases in high-profile projects like the Linux kernel, glibc and OpenSSL.
> and Rust also agrees, whether overflow checks are enabled or not does not affect the memory safety
That's because in Rust, signed integer overflows are well-defined.
In C, they are not well-defined. They are undefined behavior.
> Unless reporters have figured out an ingenious way to exploit a single integer overflow, the OP's reaction is completely justified.
I agree! It is completely justified.
However, the OP's assertions that the code is perfectly safe because it looks like a harmless integer overflow and that anyone can take a look at the code and figure out that it's not a vulnerability, are not justified.
It would be OK to say that the bug is unlikely to be a vulnerability. But not that it is not a vulnerability, at least, not without a much deeper look into why it is not (which would likely include looking at the disassembled code under multiple platforms, multiple compilers and multiple compiler versions).
To be clear, I believe that the burden of proving whether the bug is (or is not) a vulnerability is not on the OP. I would say it would be on those who have assigned a high severity to the CVE.
But that still doesn't make the assertions written by the OP correct.
We seem to talk past each other. I have no doubt that signed integer overflows are undefined behaviors as defined in ISO C and should be avoided in any case, but typical compiler behaviors on UB are reasonably understood that I think its immediate effects are overstated.
That said, I should have said "to be actually exploitable" instead of "to be actually vulnerable", because vulnerabilities do not always turn into threats or risks. My bad. If you actually wanted to point this out, thank you.
> In some cases, the compiled code behaves in ways that have nothing to do with how the program was written.
Of course. Moreover completely safe code without any UB can exacerbate existing security bugs (e.g. ROP). So should we say that such code is also vulnerable or exploitable? It would be quite a stretch IMHO. Exploits need one or more vulnerabilities to be feasiable, but they can also leverage any other code at their disposal. And some vulnerabilities are weak by their own that other vulnerabilities are needed. I meant to say that signed integer overflows themselves are such ones.
There is also a weak consensus of this separation in the form of ISO C11 Annex L (Analyzability). Analyzability itself is apparently too strong and too weak at the same time [1] and not commonly implemented AFAIK, but it does define a normative list of "critical" UBs which do not include signed integer overflows.
> But that still doesn't make the assertions written by the OP correct.
I expect Daniel Stenberg to actually write something akin to my comments when he dispute the CVE.
> but typical compiler behaviors on UB are reasonably understood that I think its immediate effects are overstated
I don't dispute that usually the compiler and the compiled code behave like we expect. That is not under dispute.
What I am arguing is that sometimes, they don't behave like we expect. Instead, they behave in wildly different, unexpected, and unintuitive ways.
Since sometimes they don't behave like we expect, there is no way of knowing for sure what the effects of UB are without looking at the compiled binary code.
> So should we say that such code is also vulnerable or exploitable? It would be quite a stretch IMHO.
Sure, but in the case you are describing, the vulnerability is not in the safe code, because if the rest of the code was safe, then the safe code would not exacerbate anything.
In the OP's case, this is not true. The rest of curl could be 100% safe and yet, the bug described in the article could still be the cause of an exploitable security vulnerability.
And since the bug causes UB, there is no way to know for sure if the bug causes an exploitable security vulnerability or not just by looking at curl's source code, unlike what Daniel seems to be claiming.
> I expect Daniel Stenberg to actually write something akin to my comments when he dispute the CVE.
Sure. He should dispute the CVE and there is no reason to believe that the bug that he is describing has a security vulnerability.
But once again, his claim that the bug does not cause a security vulnerability is unsubstantiated.
The correct thing to say would be something like: "at this point, there is no reason to believe that the bug causes a security vulnerability".
He could even say that it's extremely unlikely for there to be one. But he cannot say for sure that there isn't one, just by looking at the source code.
The claims he is making contribute to proliferate misconceptions about the C language, C compilers and the security of C code, which unfortunately are too common.
I haven't read the Annex yet, but I suspect that actually achieving the goal of bounding the effects of UB is much, much harder than what it appears to be at first sight.
Right now, it is difficult or impossible to reason about the effects of UB in all cases because the tiniest assumption about the impossibility of a signed integer overflow can lead to an unbounded number of arbitrary, cascaded side effects.
Furthermore, I don't think this is something that can be easily fixed. The main reason for that is that exploiting these assumptions allows compilers to perform significant performance optimizations, and these performance optimizations are correlated with substantial transformations in the IR / compiled code, which sometimes leave the final compiled code unrecognizable compared to the source code.
If you'd prevent the compiler from performing just a single one of these optimizations, many significant real-world software projects and companies would immediately object to that, because it would have a significant performance impact in many important real-world code segments.
I'm talking about projects where a 5% performance degradation in some code segments can be considered a very significant regression.
In the end, the main way to stop UB from affecting compiled code in unexpected ways (in some cases, in extreme ways) is to actually define what happens on an integer overflow, or at least, leave it implementation-defined.
You cannot easily say "you can do whatever you want on integer overflows" while also saying "except the program may not crash just because of the overflow".
The process of assigning CVE’s has been comically broken for a while now.
It’s somehow simultaneously possible for it to be both possible for a vendor to block valid CVE assignments, and for people to make up bullshit ones like this.
It used to be that anybody could issue CVE for anything, which lead to some pretty bad CVEs. But now there's a CNA program in place, and has been for several years, where the organization can register as a CVE source for a product or a set of products, and nobody would be issuing CVEs for those products. Not sure how 2020 CVE even got in the system - you shouldn't be able to reserve 2020 CVE now, so it appears as if somebody got a CVE ID reserved three years ago and just decided for some reason to publish it as curl CVE. Not sure if the current system has any protections against such abuse...
81 comments
[ 2.9 ms ] story [ 135 ms ] threadhttps://ubuntu.com/security/CVE-2020-19909
but in the original site it's still critical https://cve.report/CVE-2020-19909
Hard to imagine how that could lead to any security compromise, the seemingly randomly assigned criticality is certainly unpleasant. Could it be that it was detected by "automated source code" and "website vulnerability" reports, when the tools very often assign HIGH, CRITICAL to random issues that aren't the problems
But even with the best people, mistakes do happen; sometimes as banal as clicking the wrong button or mixing up two tabs.
Source: Found a handfull of RCEs for popular PHP projects, some of which have CVEs.
Security roles largely are just adversarial QA.
"the story of AI being managed by a "human in the loop" is a fantasy, because humans are neurologically incapable of maintaining vigilance in watching for rare occurrences."
https://pluralistic.net/2023/08/23/automation-blindness/#hum...
Such prompts might be completely AI generated, or just flip the AI decision under review.
Integer overflows as a vulnerability class are often very bad, but usually when they're describing an attacker-controlled memory allocation size (which the attacker's buffer will then go on to overflow, often to byte-specific length accuracy). Sounds like the reviewer here could have been someone primed to think that "integer overflow" meant "integer overflow controlling a memory allocation", which doesn't seem to be the case here at all.
<https://news.ycombinator.com/item?id=36526450>
Email corrections to mods at hn@ycombinator.com.
(I've done so in this case.)
What I'd prefer is that people note the problem, email mods, and note that they've done so. Which is my standard practice.
Isn't that extortion? I wonder if India has laws that you can point to to make them go away.
For the few that we have engaged in back and forth conversation, they typically were just reporting warnings from various opensource website scanners, without completely understanding what they were talking about.
That's not to say somebody might discover a new unique vulnerability in the open source software and packages you might be using, except you wouldn't expect them to report it to your company, as some random user on the Internet, when the official projects are on github.
Alternatively if they reported a very specific issue regarding software you developed, I'm sure it would get your 100% attention. That's not been my experience so far (knock on wood).
> That's not to say somebody might discover a new unique vulnerability in the open source software and packages you might be using, except you wouldn't expect them to report it to your company, as some random user on the Internet, when the official projects are on github.
I've actually had this happen once or twice. AFAICT the situation was either that the reporter explains themselves so poorly (in very broken english) that the original project ignored them, or they are trying to maximize bounties by reporting to everyobe who uses the package instead of the actual maintainer.
> Alternatively if they reported a very specific issue regarding software you developed, I'm sure it would get your 100% attention. That's not been my experience so far (knock on wood).
It does happen (especially if you offer bounties or you are famous), but its like 1% of emails you get at most. Most reports are just incoherent non sense or people misunderstanding the output of an autonated scanner. But its worth it to pay attention for the 1%.
They are annoying though. I'm pretty sure 90% of the value proposition of hackerone is dealing with these people.
Is it "spam" in the sense of Nigerian princes and penis enlargements? No. Is it "spam" in the sense that it's the same useless crap being repeated ad nauseam? Absolutely.
There’s a lot of noise to wade through, but we occasionally get good, valid reports. We pay those a reward and fix the issues.
Our understanding is many of these reports come from people who landing a single bounty is equivalent to a month of income.
Can you elaborate on/contextualize this?
Of course the right answer is to just keep upgrading our dependencies... so our build machine doesn't fall into an infinite loop when a hacker rewrites our build scripts?
bunch of scanners (scammers too), checkers, brainless check lists instead of pure code analysis.
Sure, it is way easier to run some scanners.exe instead of deep dive into code base, understand it and find actual problems
I can't help but imagine something like this is where we're headed, given how counterproductive it can be to make decisions based on CVSS scores...
[0]: https://www.first.org/epss/model
So of course there is now huge motivation to get these CVE things, inflate them, never under-grade them, just in case ... so of course CVEs are becoming more noisy and useless, and many orgs (including my company) are now moving to EPSS. Just give it a few years though, this EPSS will probably degrade just like CVE as it becomes widely embedded in enterprise security processes.
https://github.com/curl/curl/pull/4166/commits/a42a763ebde64...
It seems the code is using a signed long.
Unfortunately, in C, signed overflow is undefined behavior. Anything can happen, and you should not assume that it is just benign behavior like wraparound. Undefined behavior, in a seemingly unrelated area, can result in a security issue somewhere else in the program thanks to how C deals with undefined behavior.
While I don’t think it is as severe as the CVE indicated, something that triggers undefined behavior in C is not to be dismissed as lightly as the article is doing.
I'm aware there are cases of overzealous compilers removing conditional code based on the incorrect assumption that overflows can never happen, but this doesn't seem to be the case here.
In the case of LLVM for example signed integer overflows will merely produce a poison value, and won't produce the actual UB if it is either optimized out or only used by instructions that can't produce UBs by themselves [1].
Compilers also tend to use the UB as an excuse to optimize things, not to break things. We only care about the UB because a faulty optimization still can cause breakages. In this particular case the poison value will eventually reach the following condition [2]:
So let's assume that `config->retry_maxtime * 1000L` was indeed always a poison value---what can reasonable optimizing compilers do? At worst they will probably evaluate the entire condition as false, because it would help the dead code elimination. Compilers can put a nasal demon in that case, but reasonable ones wouldn't. And since `config->retry_maxtime * 1000L` is not guaranteed to be a poison value all the time, this optimization is not even actually possible. The practical effect of this security bug is quite limited.[1] https://llvm.org/docs/LangRef.html#poison-values
[2] https://github.com/curl/curl/blob/c2212c05aa99bb31e4b99b0b66... (similar for `config->retry_delay`, omitted for brevity here)
You are probably correct (although it's hard to say for sure that you've considered every single compiler optimization).
But even if you are correct, the point of the parent poster still stands:
> something that triggers undefined behavior in C is not to be dismissed as lightly as the article is doing.
I agree with this.
Notice how long your explanation was. The author of the article did not provide a similar explanation, or even an abbreviated one, in order to justify the claims that the bug does not have security implications. In fact, the author didn't even have to provide such an explanation, but he could have at least acknowledged the possibility, which could then be argued to be dismissable based on his (extensive) experience.
I'm not saying that there are security implications or that the burden of proving that there aren't any is on the author of the article.
I'm only agreeing with the parent poster that you cannot easily or simply claim that the bug is not a security vulnerability, without giving some consideration to the possible impact of UB, or at least acknowledging the possibility.
Not acknowledging this possible impact can in fact reinforce misconceptions about the security implications of bugs in C code that lead to UB.
Curl already runs ubsan and fuzzer in its testing process [1]. They know what they are doing (you may disagree on the first principles of writing curl in C/C++, but it's not like that curl is not sufficiently aware of UBs), so you should have asked instead why this particular bug was not caught already.
I believe the answer is that this bug occurred in the curl's CLI interface (src/tool_*.c), not in libcurl. The current fuzzer only runs against libcurl so this bug could have slipped in. But then it is even more clear that this bug can't be that serious, because libcurl does all the heavy lifting! Integer overflows themselves are not significant, they have to be paired with other mechanisms to be actually vulnerable (and Rust also agrees, whether overflow checks are enabled or not does not affect the memory safety).
Unless reporters have figured out an ingenious way to exploit a single integer overflow, the OP's reaction is completely justified.
[1] https://daniel.haxx.se/blog/2021/12/13/keeping-curl-safe/
No, that is not true. That's a misconception. Your sentence is true for unsigned integer overflows, but not for signed integer overflows, which are undefined behavior in C.
Compilers assume that signed overflows are not possible. They exploit that assumption to perform many significant and important code optimizations, which greatly improve performance. Those optimizations can cause the program behavior to change dramatically in the case that a signed overflow would happen.
In some cases, the compiled code behaves in ways that have nothing to do with how the program was written.
In extreme (but real, documented) cases it can have effects like:
1. Security vulnerabilities being introduced in the compiled code, even though the source code appears to be perfectly safe.
2. Code that isn't called anywhere to be called.
3. The program crashing even though the code looks completely safe, and in fact would have been perfectly safe if the optimizations hadn't been performed.
4. And many more.
These are not theoretical or hypothetical effects. They are real effects that have been demonstrated in real code compiled with widely used compilers (GCC and clang), in some cases in high-profile projects like the Linux kernel, glibc and OpenSSL.
> and Rust also agrees, whether overflow checks are enabled or not does not affect the memory safety
That's because in Rust, signed integer overflows are well-defined.
In C, they are not well-defined. They are undefined behavior.
> Unless reporters have figured out an ingenious way to exploit a single integer overflow, the OP's reaction is completely justified.
I agree! It is completely justified.
However, the OP's assertions that the code is perfectly safe because it looks like a harmless integer overflow and that anyone can take a look at the code and figure out that it's not a vulnerability, are not justified.
It would be OK to say that the bug is unlikely to be a vulnerability. But not that it is not a vulnerability, at least, not without a much deeper look into why it is not (which would likely include looking at the disassembled code under multiple platforms, multiple compilers and multiple compiler versions).
To be clear, I believe that the burden of proving whether the bug is (or is not) a vulnerability is not on the OP. I would say it would be on those who have assigned a high severity to the CVE.
But that still doesn't make the assertions written by the OP correct.
That said, I should have said "to be actually exploitable" instead of "to be actually vulnerable", because vulnerabilities do not always turn into threats or risks. My bad. If you actually wanted to point this out, thank you.
> In some cases, the compiled code behaves in ways that have nothing to do with how the program was written.
Of course. Moreover completely safe code without any UB can exacerbate existing security bugs (e.g. ROP). So should we say that such code is also vulnerable or exploitable? It would be quite a stretch IMHO. Exploits need one or more vulnerabilities to be feasiable, but they can also leverage any other code at their disposal. And some vulnerabilities are weak by their own that other vulnerabilities are needed. I meant to say that signed integer overflows themselves are such ones.
There is also a weak consensus of this separation in the form of ISO C11 Annex L (Analyzability). Analyzability itself is apparently too strong and too weak at the same time [1] and not commonly implemented AFAIK, but it does define a normative list of "critical" UBs which do not include signed integer overflows.
> But that still doesn't make the assertions written by the OP correct.
I expect Daniel Stenberg to actually write something akin to my comments when he dispute the CVE.
[1] E.g. https://marc.info/?l=llvm-dev&m=143589591927876&w=4
I don't dispute that usually the compiler and the compiled code behave like we expect. That is not under dispute.
What I am arguing is that sometimes, they don't behave like we expect. Instead, they behave in wildly different, unexpected, and unintuitive ways.
Since sometimes they don't behave like we expect, there is no way of knowing for sure what the effects of UB are without looking at the compiled binary code.
> So should we say that such code is also vulnerable or exploitable? It would be quite a stretch IMHO.
Sure, but in the case you are describing, the vulnerability is not in the safe code, because if the rest of the code was safe, then the safe code would not exacerbate anything.
In the OP's case, this is not true. The rest of curl could be 100% safe and yet, the bug described in the article could still be the cause of an exploitable security vulnerability.
And since the bug causes UB, there is no way to know for sure if the bug causes an exploitable security vulnerability or not just by looking at curl's source code, unlike what Daniel seems to be claiming.
> I expect Daniel Stenberg to actually write something akin to my comments when he dispute the CVE.
Sure. He should dispute the CVE and there is no reason to believe that the bug that he is describing has a security vulnerability.
But once again, his claim that the bug does not cause a security vulnerability is unsubstantiated.
The correct thing to say would be something like: "at this point, there is no reason to believe that the bug causes a security vulnerability".
He could even say that it's extremely unlikely for there to be one. But he cannot say for sure that there isn't one, just by looking at the source code.
The claims he is making contribute to proliferate misconceptions about the C language, C compilers and the security of C code, which unfortunately are too common.
> [1] E.g. https://marc.info/?l=llvm-dev&m=143589591927876&w=4
Thanks for the link!
I had never heard about Annex L.
I haven't read the Annex yet, but I suspect that actually achieving the goal of bounding the effects of UB is much, much harder than what it appears to be at first sight.
Right now, it is difficult or impossible to reason about the effects of UB in all cases because the tiniest assumption about the impossibility of a signed integer overflow can lead to an unbounded number of arbitrary, cascaded side effects.
Furthermore, I don't think this is something that can be easily fixed. The main reason for that is that exploiting these assumptions allows compilers to perform significant performance optimizations, and these performance optimizations are correlated with substantial transformations in the IR / compiled code, which sometimes leave the final compiled code unrecognizable compared to the source code.
If you'd prevent the compiler from performing just a single one of these optimizations, many significant real-world software projects and companies would immediately object to that, because it would have a significant performance impact in many important real-world code segments.
I'm talking about projects where a 5% performance degradation in some code segments can be considered a very significant regression.
In the end, the main way to stop UB from affecting compiled code in unexpected ways (in some cases, in extreme ways) is to actually define what happens on an integer overflow, or at least, leave it implementation-defined.
You cannot easily say "you can do whatever you want on integer overflows" while also saying "except the program may not crash just because of the overflow".
The latter is almost equivalent to saying "sig...
In practice the likelihood of someone passing that value is rather low.
This seems like exactly the sort of mistake it would make, but that a human with even a little domain knowledge would not make.
It’s somehow simultaneously possible for it to be both possible for a vendor to block valid CVE assignments, and for people to make up bullshit ones like this.