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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.