Andrew Plato wrote:
>>Finding a hole absolutely does demonstrate that a product is
>>insecure.
>>
>>
>No it doesn't. Finding a hole means the person looking for holes has the ability to find holes. It does not, necessarily, mean the product is insecure.
>
Yes, it does. Once one person has discovered the hole, others can
exploit it. Regardless of what it says about who discovered it and who
wrote the exploit, it says unequivocally that the product is vulnerable,
a synonym for "insecure."
> Virtually every product ever made has security holes if you pummel them hard enough.
>
1. Not *every* product has holes if you pound hard enough.
2. The "insecure" attribute is transient; the product is insecure
until it is patched. Some problems cannot be patched, rendering
the product insecure until it is re-worked.
>>The only barrier to entry is the difficulty of deploying the attack.
>>Some vulnerabilities are difficult to exploit, and they are
>>marked "low
>>risk." Other vulnerabilities may be difficult to exploit, but
>>are easy
>>to script, and they turn into worms like Code Red.
>>
>>
>And that is a very significant consideration. It isn't enough to just go out and find holes. Those holes have to be exploited. Thousand of holes are discovered every week that never see the light of day or are quickly rendered meaningless by firewalls, OS patches, or a sea of other factors.
>
See "A Trend Analysis of Exploitation", Browne, Arbaugh, McHugh, and
Fithen, IEEE Symposium on Security and Privacy, 2001. It documents in
great detail the pattern of exploitation following the discovery of
vulnerabilities in widely deployed software.
http://www.cs.umd.edu/~waa/pubs/CS-TR-4200.pdf
>>Remember, exploits are easy to replicate. The attacker
>>doesn't have to
>>be skilled enough to write their own exploits when they have Internet
>>access.
>>
>>
>Agreed, but just because a hole is found, does not therefore follow that that hole will ravage your network and cause you unmitigated grief. It also does not mean the product with said hole is instantly unsound and should be tossed out the door.
>
On the contrary, if the hole is in widely deployed software, it almost
certainly does. See "How to Own the Internet in Your Spare Time",
Staniford, Paxson, and Weaver, USENIX Security 2002.
http://www.icir.org/vern/papers/cdc-usenix-sec02/ That Code Red and
Nimda are *still* rampaging across the Internet is largely a result of
lazy admins failing to patch known vulnerabilities.
>Furthermore, as part of any risk analysis I perform, there is a comprehensive review of the PROBABILITY of holes being exploited.
>
I think you need to take a really hard look at how you compute that
probability. It should be strongly influenced by how well known the
vulnerability is, how widely deployed the software product is, and the
value of the assets it is protecting.
Caveat: there has been a lot of research done on computing the
probability of attack, and the results have been fruitless. It turns out
to be very difficult to compute such a probability with any degree of
accuracy.
> If I look at a machine, I don't mark INSECURE on it and throw it in the trash because it has a single security issue. Again - that would be the case for virtually ALL systems.
>
I did not say that all products need to be discarded as soon as they are
found to be vulnerable. But they do need to be treated as insecure until
the vulnerability is fixed. In the case of (say) the Apache chunking
bug, or even the Microsoft IIS buffer overflow that spawned Code Red,
the vulnerability can be patched, and so the products can (at least
transiently) be regarded as "secure" once all known vulnerabilities have
been mitigated.
In other cases, such as the bio-mouse, the vulnerabilites are so
ingrained to the design that they cannot be mitigated. THEN the product
needs to be thrown out, because it cannot be repaired.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
This archive was generated by hypermail 2b30 : Wed Sep 04 2002 - 23:40:59 PDT