StackGuard: Automatic Protection From Stack-smashing Attacks

StackGuard: Automatic Protection From Stack-smashing Attacks

Post by Crispin Cow » Sat, 20 Dec 1997 04:00:00



StackGuard: Automatic Detection and Prevention of Buffer-Overflow Attacks

StackGuard provides a systematic solution to the persistent problem of
buffer overflow attacks.  Buffer overflow attacks gained notoriety in
1988 as  art of the Morris Worm incident on the Internet.  While it is
fairly simple to fix individual buffer overflow vulnerabilities, buffer
overflow attacks  continue to this day.  Hundreds of attacks have been
discovered, and while most of the obvious vulnerabilities have now been
patched, more sophisticated buffer overflow attacks continue to emerge.

StackGuard is a simple compiler technique that virtually eliminates
buffer overflow vulnerabilities with only modest performance penalties.
Privileged programs that are recompiled with the StackGuard compiler
extension no longer yield control to the attacker, but rather enter
fail-safe state.  These programs require no source code changes at all,
and are binary-compatible with existing operating systems and libraries.

StackGuard is intended to protect buggy software against stack smashing
attacks, even those attacks that have not yet been discovered.  For
instance, even though StackGuard was developed prior to the public
announcement Samba stack smashing vulnerability, the same vulnerable
Samba code when compiled with StackGuard protection was not vulnerable
to the attack.

A paper describing StackGuard will appear in the 1998 USENIX Security
Conference.  A pre-print of the paper is available (postscript and
HTML) here:

http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/

Source for the StackGuard-enhanced gcc is also here.  This software is
available under the usual GPL (GNU Public License) rules.  Security people
are invited to download and evaluate StackGuard.

StackGuard may be of particular interest to system administrators
seeking to protect their hosts from attack.  The compiler is very stable;
for instance, a StackGuard-enhanced gcc can compile itself correctly.
Programs compiled with StackGuard should both compile and link without
complaint.  However, since this is a first release of StackGuard, I
still recommend that privileged software be kept up to date with respect
to security announcements.

I am very interested in feedback on StackGuard.  Naturally, all the
usual feedback is requested (bugs, security vulnerabilities, comments
on the design, etc.).  Of *particular* interest is any alarms that
StackGuard sets off:  if someone attempts to apply a stack-smashing
attack to a StackGuard-protected program, the program will halt with an
error message instead of yielding a root shell.  This message *may*
indicate the discovery of a new stack-smashing vulnerability:  please
report it to me.  If your version of the program is current, then you
may also wish to report the problem to the author of the program in
question.

Crispin
-----
Crispin Cowan, Research Assistant Professor of Computer Science
Oregon Graduate Institute      | Electronically:
Department of Computer Science | analog:  503-690-1265

Portland, OR 97291-1000        | URL:     http://www.cse.ogi.edu/~crispin/
                Knowledge is to Wisdom as Data is to Code

 
 
 

StackGuard: Automatic Protection From Stack-smashing Attacks

Post by Glenn C. Everha » Wed, 24 Dec 1997 04:00:00



I should think that similar techniques could be used in
replacing some of the string copy routines with others
which would ensure they didn't, at least, overwrite
the return in a buffer. To the extent a system used dynamically
linked libraries, such replacements for e.g. strcpy could
reduce the number of buffer overflow attacks that would
work, and prevent these a bit earlier. No such techniques
will be 100% effective, of course, but they will help some.

(As a not entirely serious aside I wonder whether replacing
strcpy with something that just crashes the program might
be a good idea...)

> StackGuard: Automatic Detection and Prevention of Buffer-Overflow
Attacks

> StackGuard provides a systematic solution to the persistent
problem of
> buffer overflow attacks.  Buffer overflow attacks gained notoriety
in
> 1988 as  art of the Morris Worm incident on the Internet.  While
it is
> fairly simple to fix individual buffer overflow vulnerabilities,
buffer
> overflow attacks  continue to this day.  Hundreds of attacks have
been
> discovered, and while most of the obvious vulnerabilities have now
been
> patched, more sophisticated buffer overflow attacks continue to
emerge.

> StackGuard is a simple compiler technique that virtually
eliminates
> buffer overflow vulnerabilities with only modest performance
penalties.
> Privileged programs that are recompiled with the StackGuard
compiler
> extension no longer yield control to the attacker, but rather
enter
> fail-safe state.  These programs require no source code changes at
all,
> and are binary-compatible with existing operating systems and
libraries.

> StackGuard is intended to protect buggy software against stack
smashing
> attacks, even those attacks that have not yet been discovered.  
For
> instance, even though StackGuard was developed prior to the public
> announcement Samba stack smashing vulnerability, the same
vulnerable
> Samba code when compiled with StackGuard protection was not
vulnerable
> to the attack.

> A paper describing StackGuard will appear in the 1998 USENIX
Security
> Conference.  A pre-print of the paper is available (postscript and
> HTML) here:

> http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/

> Source for the StackGuard-enhanced gcc is also here.  This
software is
> available under the usual GPL (GNU Public License) rules.  
Security people
> are invited to download and evaluate StackGuard.

> StackGuard may be of particular interest to system administrators
> seeking to protect their hosts from attack.  The compiler is very
stable;
> for instance, a StackGuard-enhanced gcc can compile itself
correctly.
> Programs compiled with StackGuard should both compile and link
without
> complaint.  However, since this is a first release of StackGuard,
I
> still recommend that privileged software be kept up to date with
respect
> to security announcements.

> I am very interested in feedback on StackGuard.  Naturally, all
the
> usual feedback is requested (bugs, security vulnerabilities,
comments
> on the design, etc.).  Of *particular* interest is any alarms that
> StackGuard sets off:  if someone attempts to apply a
stack-smashing
> attack to a StackGuard-protected program, the program will halt
with an
> error message instead of yielding a root shell.  This message
*may*
> indicate the discovery of a new stack-smashing vulnerability:  
please
> report it to me.  If your version of the program is current, then
you
> may also wish to report the problem to the author of the program
in
> question.

> Crispin
> -----
> Crispin Cowan, Research Assistant Professor of Computer Science
> Oregon Graduate Institute      | Electronically:
> Department of Computer Science | analog:  503-690-1265

> Portland, OR 97291-1000        | URL:    

http://www.cse.ogi.edu/~crispin/

- Show quoted text -

Quote:>            Knowledge is to Wisdom as Data is to Code


 
 
 

StackGuard: Automatic Protection From Stack-smashing Attacks

Post by Marc Slemk » Wed, 24 Dec 1997 04:00:00



Quote:>(As a not entirely serious aside I wonder whether replacing
>strcpy with something that just crashes the program might
>be a good idea...)

That's a silly idea.

        foo = malloc(strlen(str)+1);
        strcpy(foo,str);

Also note that when you know the data is small enough for the buffer,
using strncpy is pathetic because it zeros the _entire_ buffer.
But it is dumb enough to not null terminate all the time.  strncpy()
is an annoying pile of junk for use for security purposes.

 
 
 

StackGuard: Automatic Protection From Stack-smashing Attacks

Post by Tim Newsh » Wed, 24 Dec 1997 04:00:00





: I should think that similar techniques could be used in
: replacing some of the string copy routines with others
: which would ensure they didn't, at least, overwrite
: the return in a buffer. To the extent a system used dynamically
: linked libraries, such replacements for e.g. strcpy could
: reduce the number of buffer overflow attacks that would
: work, and prevent these a bit earlier. No such techniques
: will be 100% effective, of course, but they will help some.

When you call strcpy, it doesn't know where the end of the buffer
is.  If it did, it would be trivial for it to not go past it.
Strcpy gets passed the start of the buffer to copy into, and
the start of a string to copy from.  It has no further information
about how long the buffer to copy into is, or where the return
address is located relative to it.  Such is the problem with
normal C strings.  It is not impossible to dream up a safe
string type in C, it is just that most people use the default
string type.  (Not that all buffer overflows are due to strings).

                                         Tim N.

 
 
 

StackGuard: Automatic Protection From Stack-smashing Attacks

Post by D. J. Bernste » Wed, 24 Dec 1997 04:00:00


  [ strcpy ]

Quote:> It has no further information
> about how long the buffer to copy into is, or where the return
> address is located relative to it.

Depends on how the compiler handles stack frames. If a de* can find
the return addresses, so can strcpy.

Of course, the compiler can completely eliminate the problem by storing
lower and upper bounds along with each pointer.

---Dan
Put an end to fake mailing list subscriptions. http://www.veryComputer.com/~djb/ezmlm.html

 
 
 

StackGuard: Automatic Protection From Stack-smashing Attacks

Post by Tim Newsh » Thu, 25 Dec 1997 04:00:00




:   [ strcpy ]
: > It has no further information
: > about how long the buffer to copy into is, or where the return
: > address is located relative to it.

: Depends on how the compiler handles stack frames. If a de* can find
: the return addresses, so can strcpy.

a de* can't always find the return address.

: ---Dan

                                       Tim N.