Re: [Lit.] Buffer overruns

From: Douglas A. Gwyn (DAGwyn_at_null.net)
Date: 02/01/05


Date: Tue, 01 Feb 2005 02:13:13 -0500

Paul Rubin wrote:
> I don't get this. You said you had some process discipline that if
> followed was guaranteed to prevent buffer overruns. People asked you
> what that discipline was and you said read this book. I sent away
> for a copy of the book and remarked that I didn't see anything in
> the online TOC that looked applicable to buffer overruns. Now you're
> saying the book isn't going to tell me how to avoid buffer overruns
> after all? I didn't think it would, though it looks like there's some
> good stuff in it anyway (which is why I ordered it). But we're left
> with ABC as the best known method to completely prevent overruns.

(1) No, I recommended De Marco's book as an easy way
to get a feel for part of what is a wider package of
structured software development methodologies, which
if applied in totality (including for example
targeted testing, structured walkthroughs, and
security reviews) would eliminate essentially all
cases of buffer overrun vulnerabilities (although
that is not its particular purpose). I did that
because David didn't seem to know about any of this.
There is no book devoted especially to prevention of
buffer overruns (although there are a couple that
address it as a side effect), because that is too
narrow a perspective; the real problem doesn't lie
there, but in higher levels of the development process.
If you are unhappy with the book, let me know and I'll
buy it off you. All the spare copies that my former
boss purchased were handed out to staff long ago.

(2) ABC doesn't prevent overruns. In fact it has an
effect (other than slowing down the app) *only* if there
is a (certain kind of) instance of an overrun at run
time, which is to late to prevent it. It generally
doesn't clobber storage, but when ABC "fires" a limit
*was* exceeded. It might help if you think of this as
overrunning the object's address space, rather than its
contents.



Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... free of buffer overruns, and do it cost-effectively. ... What design processes are you going to use that will eliminate the risk ... -- and whether you can do it in a way that is cheaper than ABC. ... I don't see any evidence that careful software engineering is enough to ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... > quality largely by improving security. ... > making systems fail closed where they'd otherwise fail open; ... don't have a problem with ABC being used in debugging and testing. ... But if the product isn't free of buffer overruns, ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... Actually, he's my children's uncle, but your point is taken. ... > sloganeering that anyone with a background in formal logic ought to know ... > then I'm not going to let you use the "ABC is pointless, ... > build my programs in such a way that they are free of buffer overruns" ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... buffer overruns certainly get the press, but there are a lot more ... other security breaches indicate that other methods are being used, ... and ABC won't save you from all of them. ... Randy Howard ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... The example doesn't convince me. ... Note that ABC doesn't have any of those problems. ... It does have the "worse performance" problem -- though for many apps ... buffer overruns, then ABC would not have much value. ...
    (sci.crypt)

Quantcast