Is finding security holes a good idea?

Eric Rescorla ekr at rtfm.com
Fri Jun 11 18:15:17 EDT 2004


lists at notatla.org.uk writes:

> From: Eric Rescorla <ekr at rtfm.com>
>
>>    Is finding security holes a good idea?
>  
>>Paper:    http://www.dtc.umn.edu/weis2004/rescorla.pdf
>>Slides:   http://www.dtc.umn.edu/weis2004/weis-rescorla.pdf
>
> In section 1 there's a crucial phrase not properly followed up:
>     "significant opportunity cost since these researchers
>      could be doing other security work instead of finding
>      vulnerabilities".
> What "other security work" is being used for comparison ?
>     - finding and fixing non-program flaws (such as in configuration)
>           I do a lot of this - and I'm not about to run out of it.
>           I know that _finding_ the flaws is easy.  Even finding
>           many of them systematically is easy.  Fixing them is
>           often gets stuck on the problem of that's Fred's piece
>           of work and he doesn't feel like doing it.
>     - fixing long-known and neglected bugs (are there many ?)
>     - accelerating patch uptake
>     - technical work on tolerant architectures/languages etc
>     - advocacy work on tolerant architectures/languages etc
>           (Where's Howard Aitken when you need him ?)
>     - forensics
>     - other ?
All of the above? Probably my favorite would be finding mechanical
ways to make programs more secure--e.g. stuff like Stackguard,
etc. As you say, moving to non-C languages would be a really
good start!

> Footnote 1 mentions an indirect effect of vulnerability research.
> Another one would be programmer education - but reporting yet
> another bug of a common type seems to have low value.  People
> do need to be aware that (their!) software can be faulty and in
> roughly what ways.
Good point.

> In 3.4 if proactive WHD is not worth the effort because the bugs
> get discovered anyway when they are widely exploited what does
> this say about finding vulnerabilities through their use in the
> wild ? Is this more costly but better aimed at the bugs that matter ?
> Are there cost-effective ways to do this reactive discovery ?  What
> tools would simplify it ?
Excellent point. There's no real data on this topic but my 
intuition would be that better IDS/anomaly detection would be
a useful tool here. Also, some kind of automated
forensic network recording so that when intrusions are
detected it's easy to backfigure what happened.

-Ekr

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



More information about the cryptography mailing list