Re: [Lit.] Buffer overruns
From: Douglas A. Gwyn (DAGwyn_at_null.net)
Date: 02/01/05
- Next message: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Previous message: David Wagner: "Re: [Lit.] Buffer overruns"
- In reply to: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Next in thread: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Reply: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
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.
- Next message: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Previous message: David Wagner: "Re: [Lit.] Buffer overruns"
- In reply to: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Next in thread: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Reply: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|