Ben Scott commented:

> On 17 Sep 2003, at 11:03pm, [EMAIL PROTECTED] wrote:
> > I'd say that it was more "unfortunate" than "bad".  Writing useful,
> > correct, and secure software isn't easy.
> 
>   True.  If this was some subtle design flaw, I'd be a lot more
> understanding.  But all three of these vulnerabilities were *buffer
> overflows*.  For crying out loud!  We're coming up on the 50 year
mark for
> programmable, commercial, digital computers.  In half a century, we
still
> haven't figured out something as radical as *bounds checking*?  Come on!
> 
>   Has anyone written "Runtime environments without automatic bounds
checking
> considered harmful" yet?  'cause I'm starting to think it needs to be.


You're most of the way there, Ben.  Take the last step.  The fault
lies with..   C.

Runtime environments (and languages) which were incapable by
design of pointer errors have existed and have been used for
implementation of systems large and small for more than your
half a century.  My own first professional language was COBOL -
which for all its faults was incapable of buffer overflows.
This was (in my case) in 1963.

There are very few ways to get buffer overflows.
1.  Use assembly language.
2.  Use C.

What's depressing is that we keep doing the same thing over
again ("we'll still use C, but we'll be really careful this
time, or we'll use Purify, or...") and expecting a different
result.  I've read that this is one definition of insanity.

Writing correct, secure software isn't easy.  Writing software
which doesn't overrun buffers IS easy.

-Bill
Who used assembly language to build OSs for 15 years
And who has overrun his share of buffers

_______________________________________________
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Reply via email to