Thou shalt have no other gods before the ANSI C standard 1596

Trevor L. Jackson, III

I tend to think of that as medium, too, but sure, it is a fine place to start. I don't consider it trivial to avoid all buffer overruns at that size.

Have a pointer to code or any other stuff that we could learn from? Is it written in a language we could understand for a platform we might be familiar with? Any further lessons?

Can you say any more about how you know there are no buffer overruns?

That recasting of the problem is fine by me. I don't know that we know of any way that would allow to solve the problem with any feasible amount of effort (if we insist on using C, C standard libraries, etc.), but there's certainly plenty of evidence that what we are doing now is not good enough.

I disagree. I think we pretty much have to prevent them all. That's what it means to resist an adversary. That's what it means to ask for security against a knowledgeable attacker. If there is a security hole in your app, you'd better buttume the attacker is going to find it. Until we know how to eliminate them all, I don't think we're going to have this problem licked. Anything less risks underestimating the attacker.

We've already spent far too long in the security field underestimating the attacker. (I can give many examples.) Let's not make that mistake again.

I think that is totally wrong. Anywhere that you are handling data that could be controlled by the attacker, and there is a buffer overrun in the way you handle it, you'd better buttume you could be exploited.

Any? No, not all buffer overruns can be exploited to take control of the machine. But many can be. And if you have a buffer overrun, you'd better buttume it can be exploited. I've seen too many times where security researchers found a buffer overrun, decided after careful analysis (sometimes by multiple smart people) that it probably could never be exploited -- and were wrong.

I've seen ridiculously subtle and crafty exploit techniques. I've seen exploits that rely on overwriting code. I've seen exploits that work using only the ability to write a single '-0' byte one place past the end of the buffer (nothing more). I've seen exploits that rely on nothing more than that some buffer was freed twice. I've seen exploits that were only exploitable because of the difference between memcpy() and memmove(). I've seen exploits that managed to inject arbitrary code into the program, even though the only strings allowed through the interface were alphabetic (a-z0-9) style strings. I've seen crazy stuff.

Only 5 or 10 years ago, conventional wisdom in the security field was that stack-allocated buffers were pretty much the only real danger, in practice. Oh boy, were we ever wrong.

You have to be really careful here. A little bit of paranoia is not out of place.