Re: Compiler alternatives to no-exec (was Re: non exec stack...)

Aaron J. Grier (agrier@cse.ogi.edu)
Fri, 7 Aug 1998 12:03:39 -0700


On Fri, Aug 07, 1998 at 06:20:07AM +0000, Linus Torvalds wrote:
> David Wragg <dpw@doc.ic.ac.uk> wrote:
> >So here's another compiler-based solution: The function entry code
> >saves the return address from the end of the stack frame to the start
> >of the of stack frame. The function exit code compares the saved
> >return address with the possibly overwritten one, and aborts the
> >program if it was changed.
>
> There's an even simpler fix, with the compiler just pushing 0 on entry
> to all functions, and on exit it pops it off and aborts if it is
> non-zero.

This is one of the mechanisms that OGI's StackGuard version of GCC uses
to prevent stack-smashing attacks.

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

All the StackGuard modifications to GCC are GPL'd and available at the
above URL.

> However, the proper fix is still to get rid of the buffer overflow. The
> above has the advantage that you can actually debug it fairly easily.

Right, and if the cost is low enough, then you can compile _all_ your
programs with this extra degree of protection to protect yourself
from stack smash attacks which haven't even been discovered yet.
The Immunix project at OGI is actually in the process of building a fully-
StackGuarded RedHat 5.1 distribution.

StackGuard is a user-level solution to the stack-smashing buffer overflow
problem.

----
Aaron J. Grier | agrier@cse.ogi.edu
"I generally find that a goat isn't really necessary, but bloodying
one's fingers while installing the system and SCSI chain does seem to
correlate with more reliable operation." -- Leonard N. Zubkoff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html