Re: Libsafe Protecting Critical Elements of Stacks

[crispin () WIREX COM (Crispin Cowan)]

JEFF PFOHL wrote:

> Does anyone know anything about this?
>
>  http://www.bell-labs.com/org/11356/html/security.html

Solar Designer has posted his analysis to the Linux security-audit
mailing list
http://www2.merton.ox.ac.uk/~security/security-audit-200004/0069.html .
Perry Wagle (principle StackGuard developer, cc'd) has written an
analysis comparing StackGuard to libsafe (attached).  The summary is as
follows:

   * Use StackGuard where you can, because it is safer:
        o Libsafe only wraps selected string library functions.  Buffer
          overflows affecting other library functions or user-written
          loops will not be protected
        o Libsafe attempts to wrap these functions by parsing the stack,
          but it doesn't always succeed.  In particular, libsafe depends
          on the existance of the frame pointer, and fails when it isn't
          present, as happens if the code was compiled with -fno_fp, or
          if the optimizer removed the frame pointer.
   * Use Libsafe where you cannot use StackGuard, i.e. for binary-only
     applications.

My further comment on libsafe:  the paper that the authors will be
presenting at USENIX in June presents two forms of defense ("library
intercept" and binary-rewrite (BRW)) and only the library intercept
appears to be embodied in the publicly available libsafe, which is why
libsafe only protects against overflows that use particular string
library functions.

The BRW method is a pseudo-compiler that can transform binaries into
"safe" programs by transforming the binary.  It copies program onto the
heap, inserting checks as it goes.  The copy-to-the-heap is to make
space for the additional checks.  I really like the BRW method, and hope
it becomes available.

If my understanding is mistaken, and BRW is actually in the distributed
libsafe, please correct me.

Crispin
-----
Crispin Cowan, CTO, WireX Communications, Inc.    http://wirex.com
Free Hardened Linux Distribution:                 http://immunix.org
                  JOBS!  http://immunix.org/jobs.html

<STRONG>attached mail follows:</STRONG><HR NOSHADE><P>
Lucent Bell Labs has released "libsafe" to help prevent buffer overflow
attacks (http://www.newsalert.com/bin/story?StoryId=Cop6aWbKbyteXnZC).
Their web page is (http://www.bell-labs.com/org/11356/libsafe.html).

I downloaded the source.  My assessment is that its a stack parser
with front ends for a few of the usual suspects for buffer overflows
(strcpy, strcat, getwd, gets, [vf]scanf, realpath, [v]sprintf).  The
front ends (attempt to) check the bounds of the stack frame that the
buffer resides in.

Immunix decided years ago not to do stack parsers.  GDB (the GNU
debugger) can't do it reliably in my experience on Linux/i386, why
would we be better?  Mathematically, an executing program can parse
its own stack because part of the necessary information is encoded in
data on the stack, and part is hardcoded in the program instructions.
Parsing the stack is probably [undecidably?] hard for an external
observer [a particular instance of the compiler might produce
instruction streams with decidable stack behavior].

The flaws with LibSafe are (in no particular order):

(1) LibSafe assumes that the stack grows downward, and well as other
    i386'sms.  This is a repairable nitpick.

(2) LibSafe assumes that saved frame pointers are at the beginning of
    each stack frame.  This isn't always true.  Optimizers can decide
    not to save the frame pointer, and programmers can tell the
    compiler not to save it. So, unlike StackGuard, LibSafe doesn't
    necessarily protect each stack frame.

(3) Only calls to "strcpy, strcat, getwd, gets, [vf]scanf, realpath,
    and [v]sprintf" are protected.  Statistically, this is probably
    good coverage, but the whole C paradigm is null terminated strings
    and no array bounds checks, so its not as complete as StackGuard,
    since these aren't the only routines that overflow buffers.

(4) They don't protect anything before the supposed location of the
    frame pointer on the stack.  In particular, saved registers and
    adjacent autovars to the buffer.  StackGuard is worse, it doesn't
    even protect the saved frame pointer.  Technically, StackGuard
    could put canaries most anywhere on the stack that it wants; but
    due to the nature of its "after the fact" detection, it seemed
    prudent to put canaries as close to the protected data (the return
    address "transfer of control" hook) as possible.

(5) LibSafe doesn't work if the application statically links the
    lineup of usual suspects (listed above).  It works by preloading
    the stub replacements via ELF dynamic library loading.

(6) I think they exagerate the performance hit of StackGuard
    (moderate?!?!), but that's not too unreasonable of them.  I mean,
    what *would* a objective threshold be?

Pluses are:

(1) When it works, LibSafe is proactive rather than reactive like
    StackGuard.  Buffer overflows are detected before they occur,
    rather than afterward like StackGuard.  This isn't that big a
    point, given that StackGuard detects it pretty quickly -- and most
    importantly before the transfer of control to the injected code.

(2) The LibSafe overflow exception handler is more complex (sends
    email, etc) than my default StackGuard one.  Which is more
    comfortable to do since the buffer overflow is prevented and state
    is (allegedly) not corrupt.

(3) When LibSafe works, it protects the saved frame pointer as well as
    the return address.  StackGuard only protects the return address.
    Of course, neither protects the saved registers and the other
    autovars.

(4) They don't require recompilation of the application, which beats
    StackGuard for closed-source applications.

(5) Yet again, someone gets mileage out of an idea that I have first,
    but decide is trivial.  8) 8(

They compare the performance to some unknown version of StackGuard,
and are faster.  Well, sure, they protect less stuff.

Finally, according to the article:

  Linux distributors Red Hat, Inc., Linux-Mandrake, Turobolinux and
  Debian GNU/Linux are working with Bell Labs to incorporate Lucent
  Libsafe into their software releases.

My conclusion is that I should use LibSafe to protect software that I
can't recompile, and StackGuard to protect that which I can.  The only
advantage to combining the two (that I can see) is for protecting
(some of) the saved frame pointers.

-- Perry