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

Trevor L. Jackson, III

Nothing really significant. I know of a few examples of exploits based upon errant reads, but they were were "information disclosure" or "crash the machine" vulnerabilities, rather than something that immediately leads to the ability to take control of the machine. However, if your application isn't handling any important secrets, errant reads seem like a pretty low-priority item, I would think -- it seems to be pretty rare to encounter a buffer overrun that leads to some kind of serious information disclosure vulnerability but does not allow attackers to take control of the application.

I take it this is another way of describing 2-version programming, except done at a fine granularity, and with more detailed checking of the results of the computation? I think I understand what you are suggesting. Thanks.

That makes sense. I believe it.

Wow, that sounds like a major effort. Ok, now I think I understand why you are pretty confident there were no buffer overruns. Sounds like this could do the trick, indeed.

I'm not sure we know what would be "good enough". How could we tell? The only way I know to tell is to do a controlled experiment and measure. Until we can articulate some process, try that process out, and measure its effectiveness, I don't think we will be able to tell for sure whether that process will be adequate -- i.e., whether we will be able to (justifiably) count on that process to eliminate all buffer overruns. I have yet to see such evidence provided for any process currently known.

It is necessary that there be no buffer overruns, if we want to know that there are no security holes. How could software be shipped under that constraint? One way is to use a memory-safe language.

Another way is to ship the software without knowing whether it is secure. This latter method seems to be very widely used. :-(

That could well be. Sounds like a very credible hypothesis to me.

I don't trust myself to be able to reliably distinguish a non-exploitable buffer overrun from an exploitable buffer overrun. Often I can make a pretty good guess, but I've also been wrong too many times. I don't like taking that kind of risk. Given that, I think we're pretty much forced to say that any time you find a buffer overrun, you should treat it as a defect and fix it, even if you can't immediately identify any way to exploit it.

A buffer overrun is an example where the program is doing something wrong and something that "violates the model". Putting an upper bound on exactly how much harm can be caused by that wrong is often hard to do, particularly since you cannot reason within the model (you can't buttume, for instance, that "int x = 0; f(); return x;" returns 0).

One of the characteristics that tends to make a buffer overrun exploitable is the ability to overwrite key portions of the address space: data structures that were only supposed to be maintained by the compiler (e.g., the return address or frame pointer on the stack, vtables in C++) or linker (e.g., the GOT) or libraries (e.g., private data structures maintained by malloc, such as the free list), data that the program relies upon for correct end (e.g., function pointers, the place where the OS stores your uid, data that will later be used as an argument to a system call), and so on. It is hard to come up with an exhaustive list.

Also, you can see that determining the impact of a buffer overrun can depend on how the compiler, linker, memory allocator, libraries, OS, etc. lay out memory in your program, and that can depend heavily on the platform, how the program is compiled, how it is used, etc.

Also true, and a very good point.

I think there were a few in the Linux kernel; several of the user-kernel pointer bugs (based on insufficient input validation) had this flavor. This is the first to come to mind.

Also, most format string vulnerabilities can be exploited by the attacker to read any location in memory, so all you'd need to do is pick any program that processes a secret and that had a format string vulnerability. Of course, if your program has a format string vulnerability, you're in bigger trouble, because that usually means that an attacker can take control of your program, so maybe there is no point in focusing on information disclosure in such a setting.

By the way, thank you for your very detailed and enlightening response.