Message-ID: <c83481820902270913w3743653cjf202f02a36845040@mail.gmail.com>
Date: Fri, 27 Feb 2009 12:13:58 -0500
From: Jeremy Brown <0xjbrown41@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Apple Safari ... DoS Vulnerability

I vulnerability could technically be ANYTHING of value to the attacker
that is out of the programs normal, expected, or believed behavior.
Many people have many different views and that is why some
vulnerabilities are published, some are not. A bug that is usually
considered "just a bug" could have value to someone in a specific
environment or procedure.

On Fri, Feb 27, 2009 at 10:01 AM, Michal Zalewski <lcamtuf@...edump.cx> wrote:
>> [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/
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists