Re: A way to prevent buffer overflow exploits?

pizka@informatik.tu-muenchen.de (Markus Pizka)
3 Aug 1998 17:54:16 -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)
Re: A way to prevent buffer overflow exploits? khays@sequent.com (1998-08-16)
Re: A way to prevent buffer overflow exploits? shriram@cs.rice.edu (Shriram Krishnamurthi) (1998-08-16)
Re: A way to prevent buffer overflow exploits? conway@cs.mu.OZ.AU (1998-08-16)
[6 later articles]
| List of all articles for this month |

From: pizka@informatik.tu-muenchen.de (Markus Pizka)
Newsgroups: comp.compilers
Date: 3 Aug 1998 17:54:16 -0400
Organization: Technische Universitaet Muenchen, Germany
References: 98-07-242 98-07-246
Keywords: errors, practice
Fake-Sender: pizka@sunspies12.informatik.tu-muenchen.de



  > > 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.
>
(Anton Ertl) writes:
  > 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.
  >
  > 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).


True, the return address is not the only vulnerable point. But wrong,
moving all code pointers would still not solve the problem because it
has a far wider scope. The problem is simply mixing application-level
and system-level information without the possibility to enforce a hard
separation. In stack space local objects and management objects such
as return addresses, register saves and so on are intermixed. Worse
than that, this similarly also holds for heap space. It just seems as
if no one has yet tried to mess up heap space with overflows in a
similar way. But in general, if you know the malloc library and the
application you can pretty much mess up everything, too.


--
  *****************************************
   Markus Pizka
  Tel/FAX: +49 +89 - 289 - {28197 / 22037}
  EMail : pizka@in.tum.de
  WWW : http://www.in.tum.de/~pizka
  smail : Technische Universitaet Muenchen
Institut fuer Informatik - G2
80290 Munich (Germany)
  visit : Barerstrasse 38/40, Room G207
--


Post a followup to this message

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