-----Original Message-----
From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
The point people are missing is that covering all (or even
anywhere *near* "all") the "unfortunate sequences" or "corrupted files" is
*really really* hard, Quite often, "unfortunate sequence" means something
like "issue the command to open a file" followed by "hit 'cancel' while
the
program is waiting for the next block from the disk to feed to a
decompressor
routine...
If the *only* bugs we saw in software nowadays were that esoteric, I'd agree
with you. But I'd wager that a good 80-90% of the bugs aren't in this
category; they're "someone typed 'supercalafragalisticexpialadocious' where
the programmer expected them to type 'foo'" bugs. Basic buffer overrun or
input validation cases that could have been caught by automated testing.
But unfortunately people use excuses like the "we can't catch every bug"
argument you're making to excuse themselves from looking very hard for *any*
bugs.
For another example, consider the recent post about a back door in Hawking
routers. Apparently no one at Hawking ever thought to run 'nmap' against
their router before shipping it. Should we excuse them for that because
they "had to ship before the heat death of the universe", as you put it
earlier?
How much would it have added to development time to have closed *all* the
holes
*up front* (including *thinking* of them) to stop Liu Die Yu's "Six Step
IE
Remote Compromise Cache Attack"?
Multi-step IE exploits are another category altogether. A lot of them stem
from one basic design decision -- the "security zone" model. I'm
increasingly of the opinion that the zone model is basically flawed and
there is no way to make it completely secure. But that's another topic.
