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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <200410260124.i9Q1OfBv029655@turing-police.cc.vt.edu>
Date: Mon, 25 Oct 2004 21:24:41 -0400
From: Valdis.Kletnieks@...edu
To: David Brodbeck <DavidB@...l.interclean.com>
Cc: bugtraq@...urityfocus.com,
	"'lcamtuf@...ttot.org'" <lcamtuf@...ttot.org>
Subject: Re: Update: Web browsers - a mini-farce (MSIE gives in)

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*.)

Content of type "application/pgp-signature" skipped