|
BugTraq
Preventing exploitation with rebasing Feb 04 2003 05:08AM David Litchfield (david ngssoftware com) (7 replies) Re: Preventing exploitation with rebasing Feb 05 2003 01:41PM dullien gmx de (1 replies) Re: Preventing exploitation with rebasing Feb 04 2003 10:52PM David Litchfield (david ngssoftware com) (2 replies) Re: Preventing exploitation with rebasing Feb 04 2003 02:00PM sd hysteria sk (1 replies) Re: Preventing exploitation with rebasing Feb 04 2003 11:20PM David Litchfield (david ngssoftware com) Re: Preventing exploitation with rebasing Feb 04 2003 02:00PM Torbjörn Hovmark (torbjorn hovmark abtrusion com) Re: Preventing exploitation with rebasing Feb 04 2003 11:38AM Charlie Root (weedpower home ro) (4 replies) Re: Preventing exploitation with rebasing Feb 06 2003 01:00AM Deus, Attonbitus (Thor HammerofGod com) Re: Preventing exploitation with rebasing Feb 04 2003 08:08PM Brian Hatch (bugtraq ifokr org) (2 replies) Re: Preventing exploitation with rebasing Feb 04 2003 05:26PM Alan DeKok (aland freeradius org) (2 replies) Re: Can't Preventing exploitation with rebasing Feb 05 2003 10:06AM bugtraq gaza halo nu (2 replies) Observation on randomization/rebiasing... Feb 05 2003 09:10PM Nicholas Weaver (nweaver CS berkeley edu) (1 replies) Re: Preventing exploitation with rebasing Feb 04 2003 06:38PM David Litchfield (david ngssoftware com) (1 replies) Re: [VulnDiscuss] Re: Preventing exploitation with rebasing Feb 05 2003 05:32PM Halvar Flake (halvar gmx net) Re: Preventing exploitation with rebasing Feb 04 2003 11:34AM Eugene Tsyrklevich (eugene securityarchitects com) Re: [VulnDiscuss] Preventing exploitation with rebasing Feb 03 2003 09:49PM Michal Zalewski (lcamtuf coredump cx) |
|
Privacy Statement |
>Brian Hatch <bugtraq (at) ifokr (dot) org [email concealed]> wrote:
>
>
>>People keep saying "but it won't stop everything", and that's true.
>>
>>
> Exactly. Even DES isn't "perfectly" secure, (i.e. unbreakable). It
>*obfuscates* the data, but does not *secure* it. The benefit of DES
>is that it has a provable level of obfuscation.
>
> This takes the security versus obscurity argument from the realm of
>personal opinion to one of quantitative statements. We should have a
>similar goal for this discussion.
>
With one other critical factor: Systems that can be *properly*
criticized for being "security through obscurity" have the property that
the "obscurity" factor is fixed at software release time, or earlier.
Thus the attacker need only crack the key once, and then own thousands
of copies.
Systematic diversity (as explored by me
<http://wirex.com/%7Ecrispin/crackerpatch.pdf>, Forrest et al, proposed
in Bugtraq yesterday by Huang, and here in this thread) is qualitatively
different in that the "key" (the degree of rebasing offset) can be
chosen at runtime. If it is chosen with sufficient entropy, then it is
as effective as a similar amount of entropy in your favorite crypto
system. More, because with crypto the attacker can grind on your
ciphertext off line, but with systematic diversity, the attacker has to
grind on your machine, which you tend to notice sooner or later :-)
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
Just say ".Nyet"
[ reply ]