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