Re: [Lit.] Buffer overruns

newstome_at_comcast.net
Date: 02/04/05 

Date: Fri, 04 Feb 2005 10:22:17 -0600

In sci.crypt Douglas A. Gwyn <DAGwyn@null.net> wrote:
> Mok-Kong Shen wrote:
>> Douglas A. Gwyn wrote:
>>> Who cares? The products don't overrun buffers.
>> But a buffer overrun successfully induced by hackers in an
>> OS could crash my computer. If you don't care, I do.
>
> If I didn't care about eliminating buffer overrun
> vulnerabilities, I wouldn't be spending so much
> time responding to this thread. Unlike you, I
> understand that the most important step in
> eliminating them is identifying their actual
> cause, as a preliminary step in finding a cure,
> not in applying bandages to treat the symptoms.

But while you're doing the noble work of finding and addressing the
cause, the patient is bleeding out like crazy. From the studies of
vulnerabilities that Dave Wagner cited, about 50% of patient deaths
are caused by this particular kind of bleeding. Applying a bandage
would not only be appropriate, but I think NOT applying the bandage is
simply irresponsible.

Finding the "cure" involves a massive change in common practices
(notice I didn't say "best practices") and culture. That's a long and
extremely difficult practice, and while you're pursuing it patients
are dying left and right on you. And stop with the strawman of people
not wanting to do this -- I haven't seen ANYONE even remotely argue
that ABC is any sort of ultimate fix, and the other work is vital and
ongoing.

I don't know what the cure is, and neither do you. You have some
things that you say work, but for whatever reason they haven't been
adopted by a huge portion of the software development community.
Maybe it's ignorance, maybe it's a knowing acceptance of the risk on a
cost/benefit analysis ("hey, we can sell crappy code so why bother
making it good?"), maybe it's just momentum. Frankly, from my
standpoint this really doesn't matter -- a solution that isn't used
isn't really a "solution", and the end result is that we've got lots
of production code out there that's riddled with buffer overflow
vulnerabilities. You want to change the culture? Great, go at it --
be an evangelist. If you succeed that would be wonderful, but can you
really see anything like this happening in the next 20 years? I don't,
so bandages are good.

Incidentally, when the right combination of low overhead (more from a
developer perspective than a technical perspective) and safety is
achieved, I don't know what the answer will be -- but I can almost
guarantee that it won't involve C. 

-- 
That's News To Me!
newstome@comcast.net
Quantcast