|Re: A way to prevent buffer overflow exploits? firstname.lastname@example.org (1998-07-30)|
|Re: A way to prevent buffer overflow exploits? email@example.com (1998-07-31)|
|Re: A way to prevent buffer overflow exploits? firstname.lastname@example.org (1998-07-31)|
|Re: A way to prevent buffer overflow exploits? email@example.com (Toon Moene) (1998-08-02)|
|Re: A way to prevent buffer overflow exploits? firstname.lastname@example.org (David L Moore) (1998-08-02)|
|Re: A way to prevent buffer overflow exploits? email@example.com (1998-08-03)|
|Re: A way to prevent buffer overflow exploits? firstname.lastname@example.org.OZ.AU (1998-08-04)|
|Re: A way to prevent buffer overflow exploits? email@example.com (Ray Dillinger) (1998-08-10)|
|Re: A way to prevent buffer overflow exploits? firstname.lastname@example.org (1998-08-13)|
|[9 later articles]|
|From:||email@example.com (Anton Ertl)|
|Date:||31 Jul 1998 10:53:17 -0400|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
firstname.lastname@example.org (John D. Hardin) writes:
> This has been redirected to comp.compilers from the bugtraq list at the
> suggestion of one of the correspondents. Does anybody here wish to comment
> on the idea that I have proposed, namely: modifying GCC/PGCC/etc. to use a
> second stack or other memory area for storing local variables away from the
> stack where return addresses are stored, as a way to prevent
> smash-the-stack buffer overflow exploits?
Forth has separate data and return stacks, but for a different reason
(strings are counted (not zero-terminated) in Forth, so it's generally
much safer from this kind of problem). A separate stack in C would
also allow a nicer way for passing return values that do not fit in
the return register(s).
> > > 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.
There may also be overflowable strings in the parameters (embedded in
structs). And function pointers should not be stored in an area that
may be overflowed into; similar for pointers to function pointers etc.
So I would rather have one stack for (arbitrarily indirect) code
pointers (including return addresses) and another for other
data. However, the data may be hard to separate in this way,
especially given OOP techniques.
The code pointer stack should be at an unpredictable place, otherwise
an attacker may still make the program write something into the code
pointer stack (through a pointer he overwrites).
Overall, IMO it's not worth doing, in particular due to the problems
of separating the data.
M. Anton Ertl Some things have to be seen to be believed
email@example.com Most things have to be believed to be seen
Return to the
Search the comp.compilers archives again.