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-next>] [day] [month] [year] [list]

Message-ID: <75C025AE395F374B81F6416B1D4BDEFB01C3C330@mtv-corpmail.microfocus.com>
Date: Wed, 27 Oct 2004 06:32:07 -0700
From: Michael Wojcik <Michael.Wojcik@...rofocus.com>
To: bugtraq@...urityfocus.com
Cc: Valdis.Kletnieks@...edu,
	David Brodbeck <DavidB@...l.interclean.com>
Subject: RE: Update: Web browsers - a mini-farce (MSIE gives in)

> From: Valdis.Kletnieks@...edu [mailto:Valdis.Kletnieks@...edu] 
> Sent: Monday, 25 October, 2004 21:25
> 
> On Mon, 25 Oct 2004 09:03:20 EDT, David Brodbeck said:
> 
> > 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

Moot.  Since HTML is frequently computer-generated, HTML renderers shouldn't
be designed for human-generated input.

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

I think that's a straw man, Valdis.  HTML renderers should expect malformed
HTML input, and dealing with it is not difficult.  There's simply no excuse
for buffer overflows and null pointer dereferences when processing HTML.
It's just not that hard a problem.  It's not a matter of exhaustive testing;
the kinds of bugs found by Mangleme are basic ones that any code review
should have caught - if the code was written properly in the first place.

Basic input validation and sanitization isn't that difficult.

I write comms code - client- and server-side middleware.  I wouldn't dream
of implementing a protocol with code that didn't sanity-check the data it
gets off the wire.  I don't see any reason why browser writers shouldn't be
held to the same standard.  Avoiding unsafe assumptions when processing
input should not add significantly to develompment time; if it does, you
need to retrain your developers.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus