Re: Thou shalt have no other gods before the ANSI C standard

From: Trevor L. Jackson, III (tlj3_at_comcast.net)
Date: 02/23/05 

Date: Wed, 23 Feb 2005 14:31:02 -0500

David Wagner wrote:

> Brian Inglis wrote:
>
>>daw@taverner.cs.berkeley.edu (David Wagner) wrote:
>>
>>>I don't think buffer overruns are all that easy to test for. You can find
>>>some buffer overruns through testing, but being sure that you have found
>>>them all is very hard (particularly with testing). Gaining sufficient
>>>confidence that the code is free of buffer overruns usually requires
>>>more than just testing. It is not a trivial problem.
>>
>>This is where there is disagreement between developers and others:
>>developers in this thread seem to be saying the opposite, [...]
>
>
> As far as I can tell, they are mostly guessing.

I don't dispute that.

> They can't point to
> a large piece of software built with their favorite techniques, that
> was exposed to the Internet, and that was free of buffer overruns the
> first time.

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 attitude 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 assessment
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
real-time program is <ahem> "not a recreational activity".

> (That's because it is a hard problem, not because they
> are poor programmers -- but the very first step is to admit that it
> is a non-trivial problem.) At least, I have yet to hear anyone give
> empirical evidence for their claim that buffer overruns are easy to
> prevent if we only use their development process. Meanwhile, we have
> plenty of empirical evidence that buffer overruns are uniformly hard.
> for almost everyone in this business.

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.

>
> If you ask me why avoiding buffer overruns is non-trivial, I would
> be hard-pressed to give you a definitive answer. My best guess is
> that, if you're building a big piece of software, you have thousands
> of chances to make a mistake, thousands of opportunities where (in
> many languages) any error leads to a buffer overrun vulnerability.
> Even if your error rate is only a few defects per thousand (and this
> is an amazing accomplishment which probably requires major effort to
> achieve), that's still not good enough, because just one buffer overrun
> is enough to render your system insecure.

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,
> and I don't have hard evidence for this explanation. Nonetheless, even
> though my guess at the core cause of buffer overruns is conjectural,
> my claims about the difficulty of buffer overruns are not conjectural --
> the empirical data we have available to us looks pretty much unequivocal
> at this point.

That is a generalization I find uncomfortable.

/tj3

Relevant Pages

  • Re: How to develop a random number generation device
    ... Perhaps buffer overruns can't be prevented ... to make safe code possible. ... related to process isolation (preventing one process from trashing another ... A buffer overrun is where a process trashes its own memory. ...
    (sci.electronics.design)
  • Re: Minimum spec home pc
    ... improve system stability by detecting illegal memory accesses of the kind that some program bugs and some exploits (like buffer overruns) cause and preventing them from doing any harm. ...
    (uk.comp.homebuilt)
  • Re: Thou shalt have no other gods before the ANSI C standard
    ... >>I don't think buffer overruns are all that easy to test for. ... plenty of empirical evidence that buffer overruns are uniformly hard. ... many languages) any error leads to a buffer overrun vulnerability. ... That's only a conjecture, ...
    (sci.crypt)
Quantcast