> 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 latter is almost equivalent to saying "signed integer overflows must perform two's complement arithmetic", which is what Rust does.
Because any other behavior would basically be just as unintuitive as UB in some cases, and in fact, for you to preserve the existing optimizations, in the worst case the compiled code would have to behave differently depending on not only the surrounding source code, but also any arbitrary piece of code in the entire program (due to link-time optimizations).
The email you linked to even alludes to the Annex's naivety in terms of bounding the effects of UB:
> the Annex completely fails to be useful for the purpose you intend
> That really doesn't get you much of anything.
But really, all of this is completely beside the point. I was only trying to dispute a couple of Daniel's claims, which are too strongly-worded, without actually disagreeing with anything else that Daniel is saying.
I wouldn't even disagree with those claims if they were worded a bit less strongly.
> needed more time to solve challenging tasks but made fewer errors [1]
As someone else said, I can solve problems very quickly if the solutions don't have to be correct...
But more seriously, it seems like different people might have different thresholds for when they consider a problem solved?
If you decide to go back and review the problem and solution (even just mentally) to make sure you didn't make mistakes, of course that would take longer and give you more correct answers than the person who doesn't do that?
There's no such thing as "intelligence in one area", intelligence is a general ability. You're basically ignoring everything that psychology has studied regarding intelligence.
That's just because he's using the word 'intelligence' here in place of the word 'competence', but that might just be because it's the verbiage competent people often use about themselves. This is a fair correction, but other than that he's obviously correct, being a talented software engineer doesn't give you any ability to understand the nuances of neurochemistry.
> being a talented software engineer doesn't give you any ability to understand the nuances of neurochemistry.
This is a bit of a non-sequitur based on what you said before.
Being competent or a talented software engineer is correlated with being an intelligent person, which in turn is correlated with the ability to understand the nuances of [insert topic here].
That doesn't mean that being a talented software engineer necessarily gives you the ability to understand the nuances of neurochemistry, but it is suggestive that it does, if the engineer has an interest in neurochemistry.
Also, being an intelligent person doesn't necessarily mean that you are competent or have expertise in a certain area, sure, but that is not a "logical fallacy" as the GP was saying, nor has much to do with intelligence as he seemed to be arguing (or at least, "fluid intelligence", as it is often understood).
If he simply meant "being competent or an expert in a certain area" doesn't automatically mean that you are competent or an expert in another area, then sure, I agree, and it's true that many comments on Hacker News exhibit this pattern, and this observation is often justified.
But let's not also conveniently ignore the opposite pattern, where a (presumably intelligent) person that doesn't work in a certain field can also provide much better insights than many people with many years of expertise in that same field (especially in things like, say, interpreting scientific papers, which can be legitimately hard to do correctly, for many reasons).
I don't know if you've ever noticed this, but a significant percentage of people of almost every field, even with many years of expertise, is pretty damn incompetent... you just have to step outside your bubble if you don't think so.
This includes software engineering, BTW. There are many software engineers with years of experience who don't even know what a bug tracking system or what a source code management tool are (although, not all of them are incompetent, strictly speaking). That should tell you something.
That's probably one of the reasons why you'd use GPT-4 to explain GPT-2.
Of course, if you were trying to use GPT-4 to explain GPT-4 then I think the Gödel incompleteness theorem would be more relevant, and even then I'm not so sure.
> Didn't Bitcoin lose half its value like 6 months ago?
Let's say the following statement is true: "If X is a scam then X's price eventually goes down". That doesn't necessarily make the converse statement true: "If X's price eventually goes down then X is a scam". This is a common logical fallacy. Those two statements are logically distinct propositions and if one is true, it doesn't necessarily make the other one true as well. This is just basic logic.
Which means that bitcoin's price going down does not necessarily mean that bitcoin is a scam.
Commodities' prices can fluctuate substantially. In October 2008, oil had lost more than 50% of its value in 3 months. [1]
In August 1999, gold had lost more than 70% of its value since its all-time-high in 1980. [2]
Would you also have said at those times that oil and gold are a scam because their value had gone down significantly?
(Cue the "but oil and gold are useful" responses, obliviating the fact that cryptocurrencies such as bitcoin are extremely useful in many ways, some of them unique, and that gold's industrial/ornamental utility does not justify its historical or current price by a long shot, but rather, its utility as an investment/store of value/wealth protection/diversification asset does).
I was not saying Bitcoin is a scam. I was questioning it "doing just fine" and "in fact better than most assets"
A very common logical fallacy I come across online is someone assuming a person has said something that they didn't say and writing a wall of text opposing it. Thank you for the basic logic tips on a site named Hacker News though, I appreciate the refresher :P
> At the very least, I would want to assume any civilization capable of interstellar travel to be at least 1000 years ahead of us, technologically.
My guess is that we'll be able to develop human-level artificial intelligence a lot sooner than 1000 years from now.
At which point it would be a lot easier to send AI probes to explore the galaxy and/or make first contact with another civilization than to build a generation ship.
> 5. Rightfully mentions that you should not put a plaintext password on the CLI, then proceeds to recommend you use pass in a way that puts the password back in plaintext on the CLI via a subshell which is still totally plaintext in the proc filesystem, in ps, etc, to all processes on the system running as any user.
Not to mention that the password will also get stored in plaintext in the shell's history file if the shell is in interactive mode.
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.