Date: Fri, 27 Feb 2009 16:01:22 +0100
From: Michal Zalewski <lcamtuf@...edump.cx>
To: "J. Oquendo" <sil@...iltrated.net>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Apple Safari ... DoS Vulnerability

> [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/

Powered by blists - more mailing lists