Oliver Xymoron wrote: > On Tue, 14 Sep 1999, Crispin Cowan wrote: > > The result looks like this: > > > > Interface Implementation > > > > Restriction * Firewalls * Bounds checking > > * TCP Wrappers * StackGuard > > * Randomly renaming system files > > * Randomly renumbering system > > Permutation calls (the hack proposed here * Randomly munging > > by Maniscalco) data layout > > * Fred Cohen's Deception Toolkit > > You missed a couple interesting ones. The table was intended to be a representative sample. It would be rather large if I included every security defense :-) > One is randomly offsetting the > stack. That is the (patented :-) method that Memco uses in their SEOS product. It's interesting that you point that out, as it too clearly illustrates my point: * randomly offsetting the stack is an implementation permutation, while StackGuard and array bounds checking are implementation restrictions * randomly offsetting the stack is strictly less effective: you can discover the stack offset, or inject code that is insensitive to location, via various means. > Another is having separate stacks for the call chain and local > variables. Obviously wastes a register (or an indirection), but can probably > be proved secure against stack smashing. That's a variation on the method proposed by StackShield. Hard to say whether the separate stack for the call chain is a restriction or a permutation. However, it is exactly as effective as StackGuard. I both cases, you are effectively prevented from corrupting the call chain. Crispin ----- Crispin Cowan, Research Assistant Professor of Computer Science, OGI NEW: Protect Your Linux Host with StackGuard'd Programs :FREE http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:04:39 PDT