bugtraq - Re: [Full-disclosure] Update: [GSEC-TZO-44-2009] One bug to rule them all - Firefox, IE, Safari, Opera, Chrome, Seamonkey, iPhone, iPod, Wii, PS3....

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

Message-ID: <448e9a320907210812q59f6b916mc3589e917cc6e403@mail.gmail.com>
Date: Tue, 21 Jul 2009 08:12:19 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: Thierry Zoller <Thierry@...ler.lu>
Cc: bugtraq <bugtraq@...urityfocus.com>,
	full-disclosure <full-disclosure@...ts.grok.org.uk>,
	info@...cl.etat.lu, vuln@...unia.com, cert@...t.org, nvd@...t.gov,
	cve@...re.org
Subject: Re: [Full-disclosure] Update: [GSEC-TZO-44-2009] One bug to rule them 
	all - Firefox, IE, Safari, Opera, Chrome, Seamonkey, iPhone, iPod, Wii, 
	PS3....

> + The bug was present in a 9 year old version of Netscape - draw your own
> conclusions.

There are literally thousands of HTML- and JavaScript-related denial
of service vectors in modern browsers. If you want a silly, ad hoc
example I just made up on the spot (and so could any reader of the
list), try:

foo = '<marquee>';
for (i=0;i<7;i++) foo += foo;
for (i=0;i<10000;i++) document.write(foo);

Likewise, it trahes just about any renderer (not the JS engine). So do
attempts to render highly nested XML documents, render or rescale
CANVAS objects with obscene geometries in pretty much all browsers
that support the tag... and much, much more. Heck, even silly things
such as looping window.print() are an excellent way to lock out the
UI.

In fact, such DoS scenarios are one of the most significant roadblocks
in specialized fuzzing, and need to be painfully and comprehensively
accounted for in any such code.

Because of this, I am not entirely sure it makes much value to the
community to report such patterns individually; developers may address
some bugs at random, but will likely ignore most - and because of the
nature of HTML and JavaScript, it's unlikely that a sensible set of
memory- and CPU-related constraints could be imposed without running
into scalability issues with legitimate websites, anyway.

In other words, discussing this in a more holistic way, perhaps
releasing test suites and recommending general mitigation schemes that
do not require the web to be done from scratch, might be a better
option. For example, even the approach taken by Chrome - letting
attackers take down their own tabs only - is a significant improvement
that prevents data loss pretty well in most such cases (though it's
definitely not perfect).

/mz

PS. We may argue over whether DoS attacks in browsers are a security
issue by one definition or another, but they are definitely an
usability concern and an annoyance - so rest assured, I am not trying
to dismiss your work.