Re: [Full-disclosure] Update: [GSEC-TZO-44-2009] One bug to rule them all - Firefox, IE, Safari, Opera, Chrome, Seamonkey, iPhone, iPod, Wii, PS3....
[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
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 cant 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
Infinite amount of possibilities does not necessarily equal infinite amounts of
"defenses". - Browser detects loop or script that doesnt 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 cant 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 didnt respect the
laws of physics though. Pigs fly regularly in my "code".
SMC> At some point a line needs to be drawn, though I dont
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 thats just me.