Full Disclosure mailing list archives
Re: Apple Safari ... DoS Vulnerability
From: Michal Zalewski <lcamtuf () coredump cx>
Date: Fri, 27 Feb 2009 16:01:22 +0100
[Thierry Zoller] In my book, maybe only in mine, a software bug is security relevant (sorry for the lack of clarity - it's late over here) as soon as Integrity / Availabilty / Confidentiality are under arbritary direct or indirect control of a another entity (i.e attacker). Period,
This is a neat definition, but in reality, not a very practical one (and vague enough to encompass a broad range of scenarios that have nothing to do with security vulnerabilities, including sabotage or social engineering). As an example of why such absolutes are impractical, consider that the availability of any external IT service in the world is under (limited) control of a sufficiently determined attacker, by design - simply because computers have limited resources. Unless we want to consider the presence of any such service an inherent "vulnerability" in itself, you need to place sensible, common sense constraints on the definition, such as that there must be a plausible effort-benefit ratio involved. Likewise, in that spirit, most cryptographic hash functions and PRNGs are inherently vulnerable to attacks given sufficient resources; but the function (and a system that uses it) is deemed secure if the amount of resources needed, based on currently known attack methods, is absurdly impractical. Or, processors, computer memories, and hard drives are inherently unreliable, although manufacturing processes try to keep the number of failures in check, and recover from certain errors. That said, given enough resources, and a very large number of tries, the attacker could both trigger stress conditions (e.g. elevated CPU temperature), and - unlikely, but not impossibly - eventually hit a random bit flip that benefits him in some way. Realistically, neither of these scenarios is considered a security risk until the cost-benefit ratio comes uncomfortably close to being worth pursued in practice. Security is not an abstract, formal property (attempts to define it as such are usually pretty interesting - but also out of touch), but for better or worse, the job of approximating the impact of the worst-case scenario we can think of.
You define vulnerability like a boolean that is true when the impact is of value to the attacker. "would be of value to external attacker" - I cleary disgress, I don't think that a the nature/ of a bug (vulnerability) can be defined by the "value" it has for the attacker. What about damage to the victim ? What about lost revenue, agreement breaches etc pp.
I think I specifically mentioned this in my original post?
[J. Oquendo] So let's place this Safari bug for example as a high impact and use CVSS as a guide:
The most amusing part is whenever NVD handlers accidentally enter the same issue twice, cover a regression to an earlier bug, or cover essentially the same bug affecting different products at different times - and the rigorously calculated CVSS scores would somehow deviate wildly. Security deals with unlikely events that are notoriously hard to predict and quantify, and in most cases, carry nearly unlimited damage potential (certainly not tied to an asset, as a good number of high-profile break-ins managed to demonstrate in the past); there is also no direct, cumulative gain from being mostly secure, to offset the cost of compromises. Most attempts to apply the concept of strict, by-numbers risk management to this setting end up just being goofy at best, and extremely negligent and damaging at worst. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: Apple Safari ... DoS Vulnerability Michael Krymson (Feb 26)
- Re: Apple Safari ... DoS Vulnerability Thierry Zoller (Feb 26)
- Re: Apple Safari ... DoS Vulnerability Michal Zalewski (Feb 26)
- <Possible follow-ups>
- Re: Apple Safari ... DoS Vulnerability Thierry Zoller (Feb 27)
- Re: Apple Safari ... DoS Vulnerability J. Oquendo (Feb 27)
- Re: Apple Safari ... DoS Vulnerability Michal Zalewski (Feb 27)
- Re: Apple Safari ... DoS Vulnerability Jeremy Brown (Feb 27)
- Re: Apple Safari ... DoS Vulnerability Valdis . Kletnieks (Feb 27)
- Re: Apple Safari ... DoS Vulnerability Michal Zalewski (Feb 27)
- Re: Apple Safari ... DoS Vulnerability J. Oquendo (Feb 27)