Me: OpenSSH is one of the most secure apps ever written, even in C C Haters: no it’s not! Several RCE bugs! Me: prove it. Show me a working exploit. *crickets* FUD and Security pedanticism is unbecoming of our insustry, Pals.
-
-
Creating situations that are easily avoidable doesn’t prove your point, it proves mine. :)
-
What about the situation in the above code is easy to avoid? I've shown the snippet to rooms full of people who do code audits for a living. Maybe 1 in 30 even gets what the problem is. Regular engineers? Zero out of 30.
-
That’s total nonsense. No one that does professional code auditing would miss that. It’s the most basic C issue. I feel like you’re just trying hard to make your point. There are far more serious undefined issues. Evading this is cake.
-
A majority of my public exploits since ~2005 have come from this class. See the LZ4/LZO bug from 2014 as an example.
-
*COUGH*INDUSTRYFULLOFCHARLATANS*COUGH* Computers are magic rocks that we tricked into counting time and doing math really fast with lightning.

-
Worse issue: evaluate pointer arithmetic in kernel land and tell me if the kernel can correctly verify whether a pointer will be dereferenced in userland or kernel land ;)
-
“Professional code auditors” not grokking this stuff is because infosec “professionals” are not engineers. So maybe engineers who write C for a living should be respected a bit more.
-
Just because a bunch of infosec pros don’t get this means nothing to me when infosec pros can’t code for crap.
End of conversation
New conversation -
-
-
I might be in the zero category. What seems to be the problem? Is it that in the function declaration foo pointer is not declared const? Or is SIZE the problem?
-
Overflow of signed integers is undefined. It is usually twos complement behaviour, as the underlying hardware. However, the compiler has leeway with optimizations. Compile the above with gcc -O0, and it generates safe code. Compile with -O3, gcc eliminates the bounds check!
-
So, if I understand correctly, n could overflow by choosing a big enough count and a big-sized struct foo. Now I see it. Thx
-
You'd think that this would be covered by checking whether n is less than zero, which it would be if it overflowed, right? The gotcha here is that it isn't, due to interaction with the optimizer.
End of conversation
New conversation -
-
-
What's the issue with that code? It should be an unsigned overflow because of the integer promotion, so there shouldn't be any undefined behaviour as far as I can tell?
-
Yup, I screwed that one up. Might post an actually UB example later (really, just pass the element size as an int parameter to get it).
-
But you're not demonstrating undefined behaviour, you're demonstrating using the wrong type for the job (int rather than size_t)
-
The UB follows from that mistake. It's easy to make though, once the type is hidden behind a typedef, or some API chooses to use negative values for error codes.
-
Right, but I don't believe this is something that is a surprise to most engineers and auditors. Sure, the actual issues resulting from it might, but checking the types are appropriate (e.g. size_t/ssize_t for sizes and counts) is an important and well-known step.
-
The argument is not that it is impossible to write correct code. Just that it takes effort and skilled people. It's still hard to get right, and easy to get wrong.
-
The only undefined behaviour that I've seen catch someone out (although it didn't cause any actual issues in practice, with any optimization level) was the left-shift casting to a 32-bit signed integer (e.g. (0x80 << 24) is an int, rather than an unsigned int).
-
Now, my point is that this undefined behaviour that you're talking about generally does not catch out engineers (especially with warnings emitted by modern compilers). I understand what you're trying to say but I don't find your examples compelling.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.