[7526] in bugtraq
Re: A way to prevent buffer overflow exploits? (was: "Any user
daemon@ATHENA.MIT.EDU (Crispin Cowan)
Wed Aug 5 12:23:38 1998
Date: Tue, 4 Aug 1998 10:11:52 -0700
Reply-To: Crispin Cowan <crispin@CSE.OGI.EDU>
From: Crispin Cowan <crispin@CSE.OGI.EDU>
To: BUGTRAQ@NETSPACE.ORG
This is a multi-part message in MIME format.
--------------FC71E981BF5DCA23B37F71BF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Re-post of my own message lost on the Bugtraq server:
John D. Hardin wrote:
> On Tue, 28 Jul 1998, Cy Schubert wrote:
>
> > What makes MVS (and VM) so impervious to attack is that the S/390
> > hardware doesn't rely on a stack, making effective buffer overruns
> > considerably more difficult. (A little off topic :)
More specifically, the 360/370/390 architecture writes the return address
into the code space just ahead of the function entry point. Poof: no stack
:-), and no recursion :-(
> (to continue the topic drift, and throw some ideas into the pot...)
>
> I wonder how feasible it would be to modify GCC to generate code with two
> stacks (or something equivalent): one for local variables, the other for
> parameters and return addresses.
We considered this approach when we were designing StackGuard (
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ ) but rejected it
for the following reasons:
* requires much more intrusive changes to the compiler than StackGuard
does
* breaks compatibility with existing libraries
Other than that, yeah it'll work. On the other hand, StackGuard already
exists. StackGuard works by doing integrity checks on the stack each time a
function returns: stack smashes are not prevented, but they are detected
before the program jumps to the attacker's code, preventing the exploit from
completing. StackGuard is compatible with existing libraries (i.e. a
StackGuard-protected program can link with an ordinary library) and pretty
much stomps stack smashing vulnerabilities in vulnerable code. In addition,
if someone tries to perpetrate a stack smash, you get an intruder alert in
your syslog.
> Might moving the local variables away
> from the return addresses this way be a relatively cheap way to prevent
> buffer overflow exploits without having to recode all of the applications
> or using expensive bounds-checking?
The performance penalties of StackGuard are nominal. We could not measure any
significant performance penalty in a StackGuard-protected Apache web server
when we benchmarked it with WebStone.
> Or how about allocating space for all local variables from the system heap
> automatically and transparently rather than placing them on the stack?
I agree with Glass: heaps are slow. Consider the difference between the SML
and CAML implementations of the ML language. SML uses every compiler
optimization hack in the book, and passes arguments on the heap. CAML uses
trivial optimizations, passes its arguments on the stack, and frequently
beats SML in performance.
> Or how about automatically allocating space just for local strings? This
> would take care of buffer overflows with minimal impact, wouldn't it?
That would break the C standard, which states that local variables are
allocated in consecutive memory, with optional padding between them.
> Granted, fixing the applications is the better long-term solution, but
> these might be ways to buy time to do the auditing and correction.
Absolutely. StackGuard's intruder alert also tells you which function got
smashed, so you can go fix it, or if you don't have the source, e-mail the
report to the code maintainer.
Crispin
-----
Crispin Cowan, Research Assistant Professor of Computer Science, OGI
StackGuard: protect your software against Stack Smashing Attack
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
Support Justice: Boycott Windows 98
--------------FC71E981BF5DCA23B37F71BF
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <35C0B28F.72F11952@cse.ogi.edu>
Date: Thu, 30 Jul 1998 10:51:11 -0700
From: Crispin Cowan <crispin@cse.ogi.edu>
Organization: Oregon Graduate Institute
X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: "John D. Hardin" <jhardin@WOLFENET.COM>
CC: BUGTRAQ@NETSPACE.ORG
Subject: Re: A way to prevent buffer overflow exploits? (was: "Any user can panic OpenBSD machine" flamefest)
References: <Pine.LNX.3.96.980729085541.23601D-100000@gypsy.rubyriver.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
John D. Hardin wrote:
> On Tue, 28 Jul 1998, Cy Schubert wrote:
>
> > What makes MVS (and VM) so impervious to attack is that the S/390
> > hardware doesn't rely on a stack, making effective buffer overruns
> > considerably more difficult. (A little off topic :)
More specifically, the 360/370/390 architecture writes the return address
into the code space just ahead of the function entry point. Poof: no stack
:-), and no recursion :-(
> (to continue the topic drift, and throw some ideas into the pot...)
>
> I wonder how feasible it would be to modify GCC to generate code with two
> stacks (or something equivalent): one for local variables, the other for
> parameters and return addresses.
We considered this approach when we were designing StackGuard (
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ ) but rejected it
for the following reasons:
* requires much more intrusive changes to the compiler than StackGuard
does
* breaks compatibility with existing libraries
Other than that, yeah it'll work. On the other hand, StackGuard already
exists. StackGuard works by doing integrity checks on the stack each time a
function returns: stack smashes are not prevented, but they are detected
before the program jumps to the attacker's code, preventing the exploit from
completing. StackGuard is compatible with existing libraries (i.e. a
StackGuard-protected program can link with an ordinary library) and pretty
much stomps stack smashing vulnerabilities in vulnerable code. In addition,
if someone tries to perpetrate a stack smash, you get an intruder alert in
your syslog.
> Might moving the local variables away
> from the return addresses this way be a relatively cheap way to prevent
> buffer overflow exploits without having to recode all of the applications
> or using expensive bounds-checking?
The performance penalties of StackGuard are nominal. We could not measure any
significant performance penalty in a StackGuard-protected Apache web server
when we benchmarked it with WebStone.
> Or how about allocating space for all local variables from the system heap
> automatically and transparently rather than placing them on the stack?
I agree with Glass: heaps are slow. Consider the difference between the SML
and CAML implementations of the ML language. SML uses every compiler
optimization hack in the book, and passes arguments on the heap. CAML uses
trivial optimizations, passes its arguments on the stack, and frequently
beats SML in performance.
> Or how about automatically allocating space just for local strings? This
> would take care of buffer overflows with minimal impact, wouldn't it?
That would break the C standard, which states that local variables are
allocated in consecutive memory, with optional padding between them.
> Granted, fixing the applications is the better long-term solution, but
> these might be ways to buy time to do the auditing and correction.
Absolutely. StackGuard's intruder alert also tells you which function got
smashed, so you can go fix it, or if you don't have the source, e-mail the
report to the code maintainer.
Crispin
-----
Crispin Cowan, Research Assistant Professor of Computer Science, OGI
StackGuard: protect your software against Stack Smashing Attack
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
Support Justice: Boycott Windows 98
--------------FC71E981BF5DCA23B37F71BF--
