|
BugTraq
Re: Buffer overflow prevention Aug 14 2003 05:26PM Mariusz Woloszyn (emsi ipartners pl) (6 replies) Re: Buffer overflow prevention Aug 14 2003 11:27PM Shaun Clowes (shaun securereality com au) (1 replies) Re: Buffer overflow prevention Aug 15 2003 06:48PM Crispin Cowan (crispin immunix com) (1 replies) Re: Buffer overflow prevention Aug 17 2003 11:09PM Shaun Clowes (shaun securereality com au) (1 replies) Re: Buffer overflow prevention Aug 14 2003 07:37PM Theo de Raadt (deraadt cvs openbsd org) (3 replies) Re: Buffer overflow prevention Aug 14 2003 09:14PM Gerhard Strangar (gerhard brue net) (1 replies) Re: Buffer overflow prevention Aug 14 2003 09:43PM Theo de Raadt (deraadt cvs openbsd org) (1 replies) Re: Buffer overflow prevention Aug 14 2003 07:17PM Timo Sirainen (tss iki fi) (1 replies) Re: Buffer overflow prevention Aug 14 2003 06:47PM Jedi/Sector One (j pureftpd org) (2 replies) Re: Buffer overflow prevention Aug 15 2003 09:41AM Peter Busser (peter trusteddebian org) (2 replies) Re: Buffer overflow prevention Aug 16 2003 01:36AM Mark Tinberg (mtinberg securepipe com) (2 replies) |
|
Privacy Statement |
>I think it's generally accepted that homogenity breeds insecurity, in
>which case it makes sense to try to be as different from everyone else
>as possible even if that doesn't make it impossible for someone to break
>you.
>
That is a commonly held view, but I would not say it is widely accepted.
I certainly don't accept it.
Heterogeneity increases survivability of the *species*, but does little
to protect the individual. A site manager seeking to protect their own
servers cares little if an attack that takes them down doesn't take down
their competitors. In fact, it's kind of bad if heterogeneity means that
you go down and your competitors don't. At most, you could say that
running the most common system makes you somewhat more vulnerable to
attack, and you should take that into consideration when planning your
security.
So heterogeneity is really just security by obscurity, dressed up to
sound pretty. It also comes at a cost: in direct proportion to the
security benefits of running an obscure system is elevated operational
costs due to incompatibilities induced by your diversity. Exactly what
those incompatibility costs are varies according to the ways in which
you diverge from others. For that matter, so do the security benefits
vary according to what aspects of your system you diversified.
So before spending a bucket of $ on contrived diversity, consider
spending that $ on actual security mechanisms: you will get a much more
predictable ROI.
Caveat: there is a gray spectrum between natural diversity (Windows vs.
Linux vs. BSD) and synthetic diversity (PAX/ASLR, PointGuard). The
former are diverse, but the ways in which they are divers are rigidly
fixed aspects of system architecture, and cannot be changed. The latter
use cryptographically secure random numbers (to the extent possible) to
provide per-instance diversity that is readily changed, much like crypto
session keys. Cryptography itself is just a form of obscurity, albeit
with some very important properties surrounding key management.
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Chief Scientist, Immunix http://immunix.com
http://www.immunix.com/shop/
[ reply ]