Is finding security holes a good idea?

[Damien Miller]

Eric Rescorla wrote:
>>I don't find that argument at all convincing.  After all, these bugs *are*
>>being found!
> 
> Well, SOME bugs are being found. I don't know what you mean by
> "these" bugs. We don't have any real good information about
> the bugs that haven't been found. What makes you think that
> there aren't 5x as many bugs still in the code that are basically
> like the ones you've found?

If developers are just treating bugs as isolated defects, and not
searching for typologies of problems then this may be true. If we search
for common problems and repair all that we find, then we will do better.
In many cases, this doesn't take as much additional work as finding the
first instance. Sometimes it can be as little work as writing a regexp.

Of course, not all bugs are as easy as replacing strcpy (e.g. integer
overflows are subtle), but this approach is working. What was the last
trivial buffer overflow in a *BSD?

> I don't think that's clear at all. It could be purely stochastic.
> I.e. you look at a section of code, you find the bug with some
> probability. However, there's a lot of code and the auditing
> coverage isn't very deep so bugs persist for a long time. 

I suspect that auditing coverage is usually going to be very similar to
the search patterns used by blackhats - we are all human and are likely
to be drawn to similar bugs. Auditing may therefore yield a superlinear
return on effort. Is that enough to make it a "good idea"?

-d

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