Re: A way to prevent buffer overflow exploits?

anton@mips.complang.tuwien.ac.at (Anton Ertl)
31 Jul 1998 10:53:17 -0400

          From comp.compilers

Related articles
Re: A way to prevent buffer overflow exploits? jhardin@wolfenet.com (1998-07-30)
Re: A way to prevent buffer overflow exploits? albaugh@agames.com (1998-07-31)
Re: A way to prevent buffer overflow exploits? anton@mips.complang.tuwien.ac.at (1998-07-31)
Re: A way to prevent buffer overflow exploits? toon@moene.indiv.nluug.nl (Toon Moene) (1998-08-02)
Re: A way to prevent buffer overflow exploits? dlmoore@pgroup.com (David L Moore) (1998-08-02)
Re: A way to prevent buffer overflow exploits? pizka@informatik.tu-muenchen.de (1998-08-03)
Re: A way to prevent buffer overflow exploits? fjh@cs.mu.OZ.AU (1998-08-04)
Re: A way to prevent buffer overflow exploits? bear@sonic.net (Ray Dillinger) (1998-08-10)
Re: A way to prevent buffer overflow exploits? eodell@pobox.com (1998-08-13)
[9 later articles]
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: 31 Jul 1998 10:53:17 -0400
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 98-07-242
Keywords: errors, forth

  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
--


Post a followup to this message

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