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/
