Comment Re:What about a re-implementation... (Score 1) 304
Seriously, for performance reasons this dev-team bypassed malloc of all things; do you really want to assert that they wouldn't have bypassed a bounds-checker?
How would they have bypassed the bounds-checker? About the only way would have been to say int[] all_my_programs_data = new int[1000000000] and then write an interpreter for their own language that uses that array as its data store!
Let's take the example from XKCD: "HAT (500 letters)". To read past the end of the "HAT", they would have had to manually copy that string to some communal store, like all_my_programs_data, and then read past the end. Aside from completely ignoring the language runtime and implementing your own on top, in a language with enforced bounds checking you would not have been able to read past the end of "HAT"!
I've only clicked on your reply a couple minutes ago, but aside from "change the language runtime to no longer enforce bounds checks", I literally cannot think of any other way you would bypass a language's bounds checks.
Everything else, like overruns, overreading, etc is a result of that decision.
No it isn't! It's almost entirely orthogonal!
The OpenBSD malloc that they bypassed makes exploits of already compromised programs harder; that's why Theo refers to "exploit mitigation". If OpenSSL didn't have the overread to begin with, the fact that they replaced malloc would be a questionable decision but wouldn't have led to any exploit. And even with a hardened allocator (or most hardened allocators, anyway), the exploit is still there, it's just much harder to get anywhere near as much confidential information.
That's the only way that they aren't orthogonal: the two mistakes reinforce each other on OpenBSD. In all other respects, they are completely independent.