>"fixing" realloc will only make problems occur earlier (which i suppose is good).
Yes, you should certainly suppose it's good, because it means the difference between an early out-of-memory error and a serious security vulnerability that can result in arbitrary code execution, like a buffer overflow.
That is the point of wrappers like these: to improve security.
>if you're reallocing based on untrusted user input.. well, again, you're already in trouble.
You are in trouble, but the trouble will be considerably less severe if the untrusted input hits this function instead of hitting malloc or realloc.
> Yes, you should certainly suppose it's good, because it means the difference between an early out-of-memory error and a serious security vulnerability that can result in arbitrary code execution, like a buffer overflow.
my point is that this scenario is so improbable that it's not worth worrying about.
> You are in trouble, but the trouble will be considerably less severe if the untrusted input hits this function instead of hitting malloc or realloc
heartbleed, SQL injection, and hundreds of other vulnerabilities are more likely to occur from untrusted user input. if you overflow a realloc, you don't know where the destination address is. you're far away from the stack, too. there is very little (if any) risk. i have never come across a realloc based exploit.
there is no need to apologise. if i am wrong, i am wrong.
i must say, this is the first (or second..) time i've heard of such an attack. and, whilst i'm not saying you're incorrect, i will say this - if you take user input and act upon it without validation, you're going to have a bad time. realloc does exactly what it says it will do.
is this a fault of realloc, or the programmer that wrote that code? my opinion is that it's a fault of the programmer. and i can already see that others disagree with that.
Yes, it is programmer error, but the key takeaway is that it's pretty damn easy to make a subtle yet critical error when writing in C or C++. Even if you're a developer at Google and have been writing C/C++ for many years.
Tools and wrappers like these try to mitigate the risk of these errors.
You appear to be vehemently denying the existence of a class of bugs that has plagued programs for longer than you've been programming. Perhaps reconsider how much experience you actually have.
even though, prior to this thread, i'd never heard of 2 bugs exploiting this issue, i'm not denying their existence at all. only their likelihood of occurring.
10 years since i started programming, 7 of which i consider good enough to be "experience", is the answer to your statement. less than many here, but i'm certainly not a novice.
"Likelihood" is the wrong way to think about security vulnerabilities. Once an exploit such as this is known to be possible, attackers can contrive scenarios to exploit it.
Yes, you should certainly suppose it's good, because it means the difference between an early out-of-memory error and a serious security vulnerability that can result in arbitrary code execution, like a buffer overflow.
That is the point of wrappers like these: to improve security.
>if you're reallocing based on untrusted user input.. well, again, you're already in trouble.
You are in trouble, but the trouble will be considerably less severe if the untrusted input hits this function instead of hitting malloc or realloc.