Is finding security holes a good idea?

[Thor Lancelot Simon]

On Wed, Jun 16, 2004 at 02:12:18PM -0700, Eric Rescorla wrote:
> 
> Let's assume for the sake of argument that two people auditing
> the same code section will find the same set of bugs. So, how
> to account for the fact that obvious errors persist for long
> periods of time in popular code bases? It must be that those
> sections were never properly audited, since by hypothesis
> the bugs are obvious and yet were not found. However, this
> happens fairly often, which suggests that coverage must
> be pretty bad. Accordingly, it's easy to see how you could
> get low re-finding rates even if people roughly think alike.

Actually, I think that in this regard the answer lies in a sort of
critical mass of interest.  Ideas about where to look for what sort
of bug (or which sections of code to revisit, perhaps because a
relevant new fundamental technique has appeared in the literature, or
someone else's parser has added a popular feature, or because a protocol
specification has changed) tend to propagate through the population of
experts who might find bugs slowly at first, and then faster and faster
in what's probably an exponential way.

This suggests to me that if I happen to be out in front of the curve in
casting my eyes over code fragment _X_ or _Y_ (either because of random
luck or because I'm at the front of the wave of interest), I'd really
better fix what I can, and make that fix public; because trailing out
behind me are many, many more people each of whom has _some_ chance of
finding the bug that is correlated in a nonzero way with my having found
it.

I think that this sort of thing is going to turn out to be _very_ hard
to tease out evidence for or against using naive studies of bug commission,
discovery, or rediscovery rates; but it is my intuition based on many years
of making, finding, and fixing bugs, and of watching others eventually
redo my work in the cases in which I'd managed to fail to let them know
about it.  I would argue that in fact this pattern is not the exception;
it is the rule.

Thor

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com