Re: [Lit.] Buffer overruns

From: Paul Rubin (//phr.cx_at_NOSPAM.invalid)
Date: 02/01/05


Date: 31 Jan 2005 23:38:33 -0800


"Douglas A. Gwyn" <DAGwyn@null.net> writes:
> (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).

Well, I've worked on projects where we did all that stuff, and still
had serious bugs slip through. Maybe we didn't do it right; I don't
know. It will be interesting when the book arrives.

> (2) ABC doesn't prevent overruns.

You keep saying that, but it just isn't true. It's like saying TCAS
doesn't prevent mid-air collisions. TCAS is a system that (as I
understand it) automatically takes over the operation of both
airplanes if onboard radar on the two planes detects an imminent
collision between the planes. It overrides the manual controls and
makes two planes steer away from each other.

TCAS does NOT eliminate the pilot or controller error that almost
caused a crash, just like (as you correctly point out) ABC doesn't
eliminate the programmer error that almost caused an overrun. Your
fallacy is in confusing the programmer error with the actual overrun.
A TCAS deployment is a serious incident that is supposed to cause an
FAA investigation and all that kind of stuff, but at least the pilot
and passengers are alive to tell the tale. An ABC trap is the same
way.

> In fact it has an effect (other than slowing down the app) *only* if

And TCAS has an effect (other than adding to the plane's takeoff
weight and electricity budget) *only* if etc. But TCAS is still
considered a good idea.

> there is a (certain kind of) instance of an overrun at run time,
> which is to late to prevent it.

No, ABC prevents the overrun from happening.

> It generally doesn't clobber storage, but when ABC "fires" a limit
> *was* exceeded.

Yes, a limit on the contents of a subscript, but that limit (when storage
isn't clobbered) doesn't enable the kinds of exploits that overruns
(= storage clobbered) enable.

> It might help if you think of this as overrunning the object's
> address space, rather than its contents.

I can't quite understand that.