lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Jul 2007 14:36:50 -0400
From: "Aaron Katz" <atkatz@...il.com>
To: bugtraq@...urityfocus.com
Subject: Re: Internet Explorer 0day exploit

> Exactly. Why is it that many people seem to agree that it's less likely
> that something bad will happen if information is not disclosed.

This is the classic argument between open and closed source, and full
and delayed disclosure.  And it all boils down to one thing: there is
no evidence, either way.  When we can start looking at reviewed and
reproduced scientific studies that indicate what *really* happens when
a vulnerability is fully disclosed, versus what happens when a
vulnerability is kept quiet until the manufacturer is able to fix it,
then we'll be able to have a good conversation.  Until then,
*everything* is theoretical.


> There is likely more "good" people out
> there than "bad". If x % of the good guys look at it, they will likely
> count for a higher number of people as compared to an equal % x of the
> bad.

But there are the classic problems with this approach.  We don't know
what percentage of machines will be instantly protected.  We do not
know how many machines will be protected only once the vendor offers a
patch.  We do not know how many machines will never be protected.

We do know that the bad guys now know about the exploit (Kerkhoff's
assumption), and that there is *some* number of machines that s/he can
now exploit, which s/he could not have exploited if (a) s/he didn't
discover, or otherwise know about the vulnerability, and (b) the good
guy who discovered the vulnerability had waited for the vendor to
release a patch.

But, the classic problem with the argument I'm offering is that we
don't know if the attacker has found the vulnerability already, and
that full disclosure gives the good guys the opportunity to protect
themselves.

But we simply don't know the numbers, or even have any reasonable
guesses (not just based on feelings, but based on hard evidence).  How
many good guy swill protect themselves when full disclosure is made?
How many bad guys will suddenly know about an attack that they didn't
know about, before?


Oh, and someone mentioned something about partial disclosure - state
"product Y has a vulnerability in location X, but I'm not telling you
how to exploit it".  10 years ago, I saw this a lot (I haven't read
bugtraq for 10 years), and, literally within days, there would be an
exploit posted by another researcher who wanted to make a name for
himself.  Therefore, there is no such thing as "partial disclosure".
If it's publicly disclosed, even with minimal information, then it
should be considered fully disclosed.


However, with the intent of actually adding something to this
discussion, rather than going in the exact same conversational circles
that have been going for more than 10 years.

There are things we can consider, within the each of the realms of
disclosure, independently, in an effort to weigh the risks.  I expect
I'm not the first to say this, but I think it's more interesting to
try and investigate the two concepts, completely independently from
each other, rather than for the strict purpose of comparing them.
And, if we are ever to have a chance to compare the two types of
disclosure, we must have a very good understanding of the baggage that
each type of disclosure entails.

I find it easier to think about delayed disclosure, rather than full
disclosure, to start.

I imagine it would be reasonable to propose that the complexity of
both discovering and exploiting a vulnerability would be worth
considering.  The idea, here, would be that a vulnerability that is
more difficult to find would be less likely found by anyone - good or
bad.  By definition, it's less likely that the bad guy has found it,
so it's safer to work with the vendor than it is to publicly disclose
the problem.  (Note: "less likely" and "safer" with regards to a more
easily discovered vulnerability having already been discovered by a
bad guy, not with regards to full disclosure being better or worse).

At the same time, it would seem reasonable to propose that the
popularity of the particular product should have bearing, as well.  It
seems well accepted that a more popular product will have more bugs
(and more vulnerabilities) discovered in it, both by the good guys and
by the bad guys.  Therefore, if a vulnerability is discovered in a
less popular product, it is again probably safer to keep it quiet
until the vendor supplies a patch.  (Note: safer with regards to a
more popular product, not with regards to full disclosure being better
or worse).

--
Aaron

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ