Re: Stack growth direction to thwart buffer overflow attacks

From: Bernd Paysan (bernd.paysan_at_gmx.de)
Date: 08/13/03


Date: Wed, 13 Aug 2003 14:12:52 +0200

John Cochran wrote:
> You can just as easily have the heap grow downwards. Therefore there is
> no reason to object to an upward-growing stack on that basis.

You can even have a heap that grows upward and downward, e.g. one side for
fixed location objects, and the other for dangling pointers, which can be
compacted.

However, growing the stack upwards doesn't help a bit, since usually buffer
overflows have both a caller (to return to), and a callee (to be returned
from), and the exploit now would use the callee's return (e.g. return from
gets()).

The only cure for buffer overflows is to cure the buffer overflow itself.
There are other possibilities to cure symptoms, which more or less fail to
deliver security:

* have a separate stack for buffers - may be exploited by a buffer overflow
writing into another buffer which contains commands or configuration stuff.

* separate return stack: still exploitable if you have object or function
pointers as local variables.

* non-executable stack or w^x pages - fails completely, since you can also
use threaded code (ret is goto *sp++, threaded code is goto *ip++, so
sp=ip), using libc as entry point. You'll find enough parameter cleanup
codes followed by ret to make this sort of attack feasible; and after all:
all you need is to make your malicious code executable, which is just a
single OS call away.

* guard markers: exploiter writes the guard markers himself. This can be
made tough since you could have a random guard marker per process, and even
a 32 bit word means that you have to do 2G attacks on average until you
succeed.

Guard markers for buffers are a good way to catch overflows, anyway. I use
weak guards in my heap: each buffer has its length before and afterwards
(and for dangling pointers a back-pointer). The heap's integrity is checked
periodically. This works well against inadventent buffer overflows, but
won't work for exploits. The back-pointer of dangling pointers could help,
since for integrity, this has to be a loop (back-pointer points to
forward-pointer); and the attacker often won't be able to fake both of
them.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/


Relevant Pages

  • Re: Stack growth direction to thwart buffer overflow attacks
    ... However, growing the stack upwards doesn't help a bit, since usually buffer ... The only cure for buffer overflows is to cure the buffer overflow itself. ... * guard markers: exploiter writes the guard markers himself. ...
    (comp.security.unix)
  • Re: The coming death of all RISC chips.
    ... different area of memory than the "stack", ... Any arbitrarily indirect pointer to code that can be ... overwritten by a buffer overflow is a potential hole (and an actual ... ways to exploit buffer overflows. ...
    (comp.arch)
  • Re: Why are variables stored on the stack?
    ... Buffer overflows are a more serious security problem on the stack ... not the heap, so that a malicious stack overflow can execute arbitrary ...
    (comp.lang.c)
  • [NEWS] How to Remotely and Automatically Exploit a Format Bug
    ... Exploiting a format bug remotely is not as difficult as one would think. ... We will use very minimalist server along this paper. ... Since the buffer is directly available to a malicious user, ... Guessing the address of the shellcode in the stack ...
    (Securiteam)
  • [NEWS] Multiple ValiCert Security Problems
    ... * Enterprise VA Host Server for processing validation requests VA API ... Multiple buffer overflows exist in the CGI script, forms.exe, which is ... Analysis of the code and stack contents reveals that the unchecked buffer ...
    (Securiteam)