bugtraq - Re: Re[2]: [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: <Pine.GSO.4.51.0907211619130.18458@faron.mitre.org>
Date: Tue, 21 Jul 2009 16:46:08 -0400 (EDT)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: Michal Zalewski <lcamtuf@...edump.cx>
Cc: Thierry Zoller <Thierry@...ler.lu>,
	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: Re[2]: [Full-disclosure] Update: [GSEC-TZO-44-2009] One bug to
  rule them all - Firefox, IE, Safari, Opera, Chrome, Seamonkey, iPhone,
 iPod,  Wii, PS3....

On Tue, 21 Jul 2009, Michal Zalewski wrote:

> The code created an oversized list, which does not seem to be that far
> from creating an overly nested DOM tree, or drawing an oversized CANVAS
> shape, or any other creating-too-many-things-for-the-renderer-to-handle
> attacks... but really, I'm not trying to be dismissive, just saying that
> a more holistic approach might be more beneficial in the long run.

I agree here.

I strongly suspect that as we collectively try to figure out how to solve
resource-consumption issues for all kinds of software, we will quickly run
into lots of complexity that may well enter the realm of undecidable
problems, and/or whose only solutions would require the creation of an
application-level resource monitor (thus killing performance) or having
some kind of external control of resource allocation (whose solution is
generally just to kill the application, still resulting in a DoS).  I
think that last sentence parsed OK...

Web browsers are basically mini-operating systems (which others may have
said before).  Since they are very closely attached to their underlying
operating system, it's not a surprise that they are some of the first to
really get hit by these kinds of reports (anti-virus also comes to mind).
But if you think of the infinite number of algorithms you could write in
Javascript, then it becomes a recipe for the death of a thousand cuts.

If you try to load the full XML downloads from cve.mitre.org into your
browser, good luck with that - you get CPU and memory consumption very
quickly (last time I checked).  But is that a vulnerability per se?  It
almost becomes a "laws-of-physics" vulnerability - if you send too much
data to an underpowered system with a small pipe, then a DoS is going to
occur because you can't violate the laws of physics.  If you enforce some
resource restrictions, then you wind up with an incomplete rendering of
data (incorrect behavior) at least.

In this particular case there's very little effort that the attacker needs
to make compared to the amount of CPU/memory that is produced, so the
attack-to-benefit workload is asymmetric and it seems reasonable to call
this a problem.  At some point a line needs to be drawn, though I don't
know where that line is.  I agree with Michal that a holistic approach
could save a lot of people a lot of pain.

- Steve

P.S. For those who are interested, some focused discussion on the topic
starts at http://attrition.org/pipermail/vim/2006-January/000461.html