[10843] in bugtraq

home help back first fref pref prev next nref lref last post

Diversity (was: IIS Remote Exploit (injection code))

daemon@ATHENA.MIT.EDU (Crispin Cowan)
Wed Jun 16 18:52:11 1999

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <37681F48.E0B06E33@cse.ogi.edu>
Date: 	Wed, 16 Jun 1999 15:03:52 -0700
Reply-To: crispin@CSE.OGI.EDU
From: Crispin Cowan <crispin@CSE.OGI.EDU>
X-To:         Dug Song <dugsong@MONKEY.ORG>
To: BUGTRAQ@NETSPACE.ORG

Dug Song wrote:

> On Wed, 16 Jun 1999, Ethan Benatan wrote:
>
> > Very true, and this is a terrifically important message to get out...
> > Diversity makes for resilience, and vice versa.
>
> see stephanie forrest's work on computer immunology:
>
>         http://www.cs.unm.edu/~immsec/
>
> and to a lesser extent, random "canary" values in StackGuard:
>
>         http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/

StackGuard came about because we investigated the approach of using
diversity to resist attack, and found it to be VERY limited in
effectiveness.  The core problem is that when you change things, you
create incompatabilities for friend and foe alike, i.e. a diversity hack
strong enough to defeat an attacker is also likely to break a lot of
YOUR applications.  This occurs because:

   * The diversity hack must preserve many invariants that are necessary
     to keep legitimate applications running, and these invariants are
     often subtle and unknown, e.g. Linux applications that only work on
     Red Hat systems.
   * Simultaneously, the diversity hack must BREAK the invariants that
the
     attacker depends on, and these invariants are mostly unknown.  If
you
     knew what they were, you would have fixed the bug :-)

Having discovered that diversity is hard to make both effective and
practical, we moved on to study what we call "restrictions."  A
restriction prohibits certain classes of behavior that are always known
to
be bad, e.g. changing the return address of an active function, which is
what stack smashes try to do, and what StackGuard prevents.

It is our conjecture that for every diversity hack that one can propose,
there is a restriction hack that is easier to deploy and more effective.
This has been true in practice as we try to construct security-enhancing
tools.

Full papers on these ideas can be found here:
http://www.cse.ogi.edu/DISC/projects/immunix/survivability.html

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/

              Microsoft:  Putting the "lame" in "layman"

home help back first fref pref prev next nref lref last post