Re: fixing all buffer overflows --- random magin numbers

From: Crispin Cowan (crispinat_private)
Date: Mon Sep 13 1999 - 17:10:35 PDT

  • Next message: Simple Nomad: "NMRC Advisory: HackerShield on Windows NT" 

    --------------757A0386B0ADD67A9B891E28
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(post sent as HTML and ASCII because there's a table that's easier to read
in HTML.  Aleph, go ahead and nuke the HTML if you prefer)

nm wrote:

> Neat idea.
>
> But, couldn't someone just take a common binary (say ls) that exists
> on the target system and reverse engineer it and begin to make a mapping
> of numbers to syscalls.

I wrote two papers last year that classified post hoc security enhancements
into a 2D grid:

   * one dimension is *what* is adapted:  the interface, or the
     implementation
   * the other dimension is what *kind* of adaptation you apply:  either a
     restriction, or a permutation

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

The papers describing this work are:

   * "Death, Taxes, and Imperfect Software:  Surviving the Inevitable", by
     Crispin Cowan, Calton Pu, and Heather Hinton, presented at the 1998
     New Security Paradigms workshop, and available here:
     http://www.cse.ogi.edu/~crispin/bugtol.ps.gz or here:
     http://www.cse.ogi.edu/~crispin/bugtol.pdf .
   * "Survivability from a Sow's Ear:  The Retrofit Security Requirement",
     by Crispin Cowan and Calton Pu, presented at the 1998 Information
     Survivability Workshop, and available here
     http://www.cse.ogi.edu/~crispin/isw98.ps.gz or here
     http://www.cse.ogi.edu/~crispin/isw98.pdf

In these papers we conclude that "Interface Permutations" (such as randomly
swizling the syscall numbers) has a problem:  it is just weak crypto.  It
makes the "current configuration of the interface" a symmetric session key
that must be shared amongst all the servers and clients.  It is a shared
secret.  You have all the usual problems of shared secrets, plus the
following problems:

   * it is a relatively small secret
   * it is often a very easy to observe secret (such as the ls reverse
     engineering hack that nm mentions)

The only advantage offered by interface permutation is that the secret is
not amenable to off-line cracking:  you have to make your guesses against
the host system, and that gives intrusion detectors a good shot at
detecting your cracking attempts.  Naturally, this just means that
attackers will infer the current configuration indrectly instead of brute
forcing it.

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/


>
>
> Nick Maniscalco
>
> At 09:37 PM 9/11/99 -0400, Dr. Joel M. Hoffman wrote:
> >I was thinking
> -- it wouldn't be too hard to make buffer overflow
> >attacks impossible.  The basic idea is to do away with binary
> >compatibility.
> >
> >In particular, I was thinking that part of building a kernel would
> >involve assigning a random number to each syscall, and creating a
> >syscall.h file with these random numbers.  A binary would only run if
> >it was compiled with the proper syscall.h, so all binaries would have
> >to be recompiled for the new kernel, but then, syscall.h could be
> >removed, and the system would be impervious to buffer overflow
> >attacks.  (One step further would involve random magic numbers in
> >every function call.)
> >
> >I would be happy to give up binary compatilibyt for the added security
> >it would add.
> >
> >Comments?
> >
> >-Joel Hoffman
> >(joelat_private)
> >



--------------757A0386B0ADD67A9B891E28
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
(post sent as HTML and ASCII because there's a table that's easier to read
in HTML.&nbsp; Aleph, go ahead and nuke the HTML&nbsp;if you prefer)
<p>nm wrote:
<blockquote TYPE=CITE>Neat idea.
<p>But, couldn't someone just take a common binary (say ls) that exists
<br>on the target system and reverse engineer it and begin to make a mapping
<br>of numbers to syscalls.</blockquote>
I wrote two papers last year that classified post hoc security enhancements
into a 2D grid:
<ul>
<li>
one dimension is *what* is adapted:&nbsp; the interface, or the implementation</li>

<li>
the other dimension is what *kind* of adaptation you apply:&nbsp; either
a restriction, or a permutation</li>
</ul>
The result looks like this:
<br>&nbsp;
<table BORDER NOSAVE >
<tr>
<td></td>

<td>Interface</td>

<td>Implementation</td>
</tr>

<tr>
<td>Restriction</td>

<td>
<ul>
<li>
Firewalls</li>

<li>
TCP Wrappers</li>
</ul>
</td>

<td>
<ul>
<li>
Bounds checking</li>

<li>
StackGuard</li>
</ul>
</td>
</tr>

<tr>
<td>Permutation</td>

<td>
<ul>
<li>
Randomly renaming system files</li>

<li>
Randomly renumbering system calls (the hack proposed here by Maniscalco)</li>

<li>
Fred Cohen's Deception Toolkit</li>
</ul>
</td>

<td>
<ul>
<li>
Randomly munging data layout</li>
</ul>
</td>
</tr>
</table>

<p>The papers describing this work are:
<ul>
<li>
"Death, Taxes, and Imperfect Software:&nbsp; Surviving the Inevitable",
by Crispin Cowan, Calton Pu, and Heather Hinton, presented at the 1998
New Security Paradigms workshop, and available here: <a href="http://www.cse.ogi.edu/~crispin/bugtol.ps.gz">http://www.cse.ogi.edu/~crispin/bugtol.ps.gz>
or here:&nbsp;&nbsp; <a href="http://www.cse.ogi.edu/~crispin/bugtol.pdf">http://www.cse.ogi.edu/~crispin/bugtol.pdf>
.</li>

<li>
"Survivability from a Sow's Ear:&nbsp; The Retrofit Security Requirement",
by Crispin Cowan and Calton Pu, presented at the 1998 Information Survivability
Workshop, and available here <a href="http://www.cse.ogi.edu/~crispin/isw98.ps.gz">http://www.cse.ogi.edu/~crispin/isw98.ps.gz>
or here&nbsp; <a href="http://www.cse.ogi.edu/~crispin/isw98.pdf">http://www.cse.ogi.edu/~crispin/isw98.pdf></li>
</ul>
In these papers we conclude that "Interface Permutations" (such as randomly
swizling the syscall numbers) has a problem:&nbsp; it is just weak crypto.&nbsp;
It makes the "current configuration of the interface" a symmetric session
key that must be shared amongst all the servers and clients.&nbsp; It is
a shared secret.&nbsp; You have all the usual problems of shared secrets,
plus the following problems:
<ul>
<li>
it is a relatively small secret</li>

<li>
it is often a very easy to observe secret (such as the ls reverse engineering
hack that nm mentions)</li>
</ul>
The only advantage offered by interface permutation is that the secret
is not amenable to off-line cracking:&nbsp; you have to make your guesses
against the host system, and that gives intrusion detectors a good shot
at detecting your cracking attempts.&nbsp; Naturally, this just means that
attackers will infer the current configuration indrectly instead of brute
forcing it.
<p>Crispin
<br>-----
<br>&nbsp;Crispin Cowan, Research Assistant Professor of Computer Science,
OGI
<br>&nbsp;&nbsp;&nbsp; NEW:&nbsp; Protect Your Linux Host with StackGuard'd
Programs&nbsp; :FREE
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/">http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/>
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<p>Nick Maniscalco
<p>At 09:37 PM 9/11/99 -0400, Dr. Joel M. Hoffman wrote:
<br>>I was thinking
<br>-- it wouldn't be too hard to make buffer overflow
<br>>attacks impossible.&nbsp; The basic idea is to do away with binary
<br>>compatibility.
<br>>
<br>>In particular, I was thinking that part of building a kernel would
<br>>involve assigning a random number to each syscall, and creating a
<br>>syscall.h file with these random numbers.&nbsp; A binary would only
run if
<br>>it was compiled with the proper syscall.h, so all binaries would have
<br>>to be recompiled for the new kernel, but then, syscall.h could be
<br>>removed, and the system would be impervious to buffer overflow
<br>>attacks.&nbsp; (One step further would involve random magic numbers
in
<br>>every function call.)
<br>>
<br>>I would be happy to give up binary compatilibyt for the added security
<br>>it would add.
<br>>
<br>>Comments?
<br>>
<br>>-Joel Hoffman
<br>>(joelat_private)
<br>></blockquote>

<br>&nbsp;</html>

--------------757A0386B0ADD67A9B891E28--

    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:03:34 PDT