Re: A way to prevent buffer overflow exploits?

  jhardin@wolfenet.com (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.


- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
--

Return to the comp.compilers page.
Search the comp.compilers archives again.