Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Bugtraq
[Top] [All Lists]

Re: Update: Web browsers - a mini-farce (MSIE gives in)

Subject: Re: Update: Web browsers - a mini-farce (MSIE gives in)
Date: Mon, 25 Oct 2004 21:24:41 -0400
On Mon, 25 Oct 2004 09:03:20 EDT, David Brodbeck said:

This has been a basic pet peeve of mine for years -- even before web
browsers came on the scene. How many times have you seen a word processor
crash due to an unfortunate sequence of commands or opening a corrupted
file, for example?  I think that kind of behavior is just unacceptable.
Software should be able to deal with any input that's thrown at it.

Two quotes come to mind:

"A program designed for inputs from people is usually stressed beyond
breaking point by computer-generated inputs. -- Dennis Ritchie

Yes, "should be able to deal with anything" *is* a laudable goal.  On the
other hand, there's a (presumed) requirement that the software actually *SHIP*
sometime before the thermal death of the universe - which means that the person
who has to make the decision on when/whether to ship has to decide whether
the ship date should be slipped *another* 3 months just because some automated
test program found that the package will crash if it gets requests from
a prime number of dolphins (the ceteans, not the football players) in the same
4-second interval.

Tough call - since *you* only know about it because some pseudo-random tester
found it, it's probably not easily found - and you *do* need to ship this 
quarter
or not make payroll.  *NOW* what do you do?

And if *that* judgment call was too easy, here's the second quote:

"Testing can prove the presence of bugs, but not their absence"
        -- E. Dijkstra

How do you actually prove a program bug-free? Remember - the automated tester
might not catch the prime-of-ceteans bug because *that* software's designer
never thought to cover that case (which is in itself a bug in THAT program),
so now you need to cover *all* the corner cases you can think of:  Prime
numbers of ceteans, prime numbers of octopi, composite numbers of each,
and attacks by chipmunks armed with RFI wands that corrupt packet checksums.

Oh, and you're not allowed to forget to test for a case. ;)

(If you think this is easy - read the entire end-user and administrator
documentation for a recent release of Apache.  Try to itemize *all* the things
that could possibly go wrong.  Then, once your brain turns to mush and you
can't think of any new ones, look over all the security-critical bugs that
Apache *has* had, and see if your list would have caught *every* *single* 
*one*.)


Attachment: pgpWaZewU3J0U.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>