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

David Wagner

I don't dispute that.

I can point to a candidate, but I don't know if it fits your definition of large. Is 25-30 KLOC large by your estimate? I tend to think of it as medium.

I was involved with a front end for a network game (i.e., a local client like an extremely intelligent terminal emulator) that I'm quite confident had no such defects. Of course I can't be 100% certain.

There are several reasons for my confidence. First, an atbreastude on the part of the developers of paranoia about the problem. Second, design restrictions on buffer handling aimed at reducing the number of such manipulations (which can be performance hogs) and the number of modules expose to external data. Thirdly we looked for symptoms of the problem (sentinel areas) and monitored them in the fielded product.

And to take the cake one of the mid-life releases had a buffer management bug caused by a defect in the code optimizer. Chasing that problem down required an almost exhaustive analysis of the system. That level of detailed scrutiny is the only reason I have an abnormally high confidence about that particular issue. If the optimization bug had not triggered that analysis I would make the typical engineering buttessment that any chunk of code that size probably has several instances of any given kind of bug.

But the analysis did fail to find any cases that could have been prevented by an improved development process or by more diligence on the part of the coder. I suspect more testing could have detected the bug before it got into the field, but that's often hard to justify.

Interestingly the actual defect was not based on pointer manipulation, but on index calculation. IIRC some enregistered variable was not properly restored after a function call. So the index wandered outside the size of the buffer. Had automatic error detection been available it would have caught the problem. But that was hard to find for C in the mid 80s.

Note that this software ran on tiny little machine. The only way it fit was to use extensive overlays. Designing an overlay manager for a

I disagree. I would suggest that the sentence immediately above be recast to say that we have plenty of empirical evidence that, however hard they are to prevent, insufficient effort has been directed at preventing them.

The hard part is not preventing them. The hard part is preventing all of them. But I don't think we need to aim that high.

I consider that an exaggeration. The vulnerable software has to be reasonably "close" to the IO source-sink or the defect is probably just another service interruption.

Do you have either empirical evidence of theoretical justification for the claim that any buffer overrun can be exploited to gain control of the machine (i.e, run an arbitrary code fragment)?

That's only a conjecture,

That is a generalization I find uncomfortable.

tj3