bugtraq - 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: <815295946.20090722142438@Zoller.lu>
Date: Wed, 22 Jul 2009 14:24:38 +0200
From: Thierry Zoller <Thierry@...ler.lu>
To: "Steven M. Christey" <coley@...us.mitre.org>
Cc: Michal Zalewski <lcamtuf@...edump.cx>,
	full-disclosure <full-disclosure@...ts.grok.org.uk>,
	bugtraq <bugtraq@...urityfocus.com>
Subject: 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....

Hi Steven,

[Removing   a   few  addresses  in CC that surely do not care too much
about this discussion]

SMC> I strongly suspect that as we collectively try to figure out how to solve
SMC> resource-consumption issues for all kinds of software, we will quickly run
SMC> into lots of complexity that may well enter the realm of undecidable
SMC> problems
First,    nobody    has    to  figure  out  how  to  "solve  [all] resource
consumption issues". That would be effort spent on a stupid idea.
Design your software expecting it to run into these
kind   of  problems  and  design  proper  generic  mitigations,  where
possible. You are set.

Has this been done before ? Yes, take google chrome as an example.

In Google chrome, tabs are separated in such a way that well, only
the  tab affected closes,  not  the  whole  browser  not
the  complete OS. So this is mitigating all these bugs by design and
reducing  the  impact  to a minimum, to a degree where I agree that it
could be ignored and not called a "vulnerability".

If someone designs software and claims that these problems cannot be mitigated
and    hence   should   be ignored or seen as "normal", in my personal
opinion, should be looking for another job.

Secondly, I really  can't  find  anything related to the advisory in your posting.
The   bug   at  hand  was  an unclamped loop "within the  browser code
itself". NOT an loop feed by an  external  source.  Comparing  it  to  downloading
huge  files  is comparing  apples  to  oranges.  Even  the impact is another
one, as that border case is accounted for.

SMC> Web browsers are basically mini-operating systems (which others may have
SMC> said before).
Surely Product managers and marketing departments have said so, surely
it can be designed to look like an OS. However comparing  the  current
existing  Browsers  to an Operation system is ludicrous at best.

SMC> Since they are very closely attached to their underlying
SMC> operating system,
Since when are browsers running Ring 0 ?

SMC> But if you think of the infinite number of algorithms you could write in
SMC> Javascript, then it becomes a recipe for the death of a thousand cuts.
Infinite  amount  of  possibilities  does not necessarily equal infinite amounts of
"defenses". - Browser  detects  loop  or  script  that doesn't exit, asks user if he
wants to stop it. Been there, done that.

SMC> If you try to load the full XML downloads from cve.mitre.org into your
SMC> browser, good luck with that - you get CPU and memory consumption very
SMC> quickly (last time I checked).
Apples and Oranges, nobody said CPU consumption is a vulnerability per
se.  The possible impact is what makes it a vulnerability or not, such as
browser crashes, OS reboots, etc pp.

I  still  have trouble to understand why some are not using the impact
of  a  bug to rate it. The resulting impact (what can be done with it,
what consequences this problem has for a user/system) is what defines
the security aspect, not necessarily the root cause.

SMC> But is that a vulnerability per se?  It
SMC> almost becomes a "laws-of-physics" vulnerability - if you send too much
SMC> data to an underpowered system with a small pipe, then a DoS is going to
SMC> occur because you can't violate the laws of physics.
If  you  have  not planed for that border case,for example the browser crashes or
the  OS  reboots and it creates "damage" as in Dataloss  - yes it is a vulnerability.
Sorry, but stupidity or lack  of  effort  has never protected somebody from
calling it what it is. Last time I checked, software code didn't respect the
laws of physics though. Pigs fly  regularly  in  my  "code".

SMC> At some point a line needs to be drawn, though I don't
SMC> know where that line is.  I agree with Michal that a holistic approach
SMC> could save a lot of people a lot of pain.
These are empty words to my ears. "holistic approach" sounds like "war
on terror". But maybe that's just me.

-- 
http://blog.zoller.lu
Thierry Zoller