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
