Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Apple Safari ... DoS Vulnerability
From: Jeremy Brown <0xjbrown41 () gmail com>
Date: Fri, 27 Feb 2009 12:13:58 -0500

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 () coredump 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/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]