Re: A way to prevent buffer overflow exploits?

jhardin@wolfenet.com (John D. Hardin)
30 Jul 1998 23:25:24 -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)
[11 later articles]
| List of all articles for this month |

From: jhardin@wolfenet.com (John D. Hardin)
Newsgroups: comp.compilers
Date: 30 Jul 1998 23:25:24 -0400
Organization: Wolfe Internet Access, L.L.C.
Keywords: question, comment

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?


Stack Guard has already been discussed.


On Wed, 29 Jul 1998, Brett Glass wrote:


> At 09:13 AM 7/29/98 -0700, John D. Hardin wrote:
>
> > 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. Might moving the local
> > variables away from the return addresses this way be a relatively cheap
> > way to prevent buffer overflow exploits without having to recode all of
> > the applications or using expensive bounds-checking?
>
> It would be a great start, though it certainly wouldn't be foolproof. (If
> the program under attack interprets commands, for example, it's still
> possible to overflow the variable into a buffer that holds commands to be
> executed. Then all you need to do is plant a dangerous command, or one
> that lets you into the system.
>
> Still, because hammering the subroutine return stack is such an easy
> thing to exploit, it'd be worth preventing it.
>
> Incidentally, some embedded compilers do a variation on the concept of a
> separate stack. They allocate parameters and locals as globals in the
> program's global data area, then use lifetime and program flow analysis
> to determine when the space can be re-used by another routine. Since
> accesses to the global data segment require shorter opcodes than access
> to the stack, this crunches the program size AND can make the code run
> faster.
>
> >Or how about allocating space for all local variables from the system
> >heap automatically and transparently rather than placing them on the
> >stack?
>
> Heaps are slow, unfortunately.
>
> >Or how about automatically allocating space just for local strings? This
> >would take care of buffer overflows with minimal impact, wouldn't it?
>
> Yes, but again, this might slow things down. The global approach would be
> better.
>
> >Granted, fixing the applications is the better long-term solution, but
> >these might be ways to buy time to do the auditing and correction.
>
> Agreed.
>
> --Brett
--
  John Hardin KA7OHZ jhardin@wolfenet.com
  pgpk -a finger://gonzo.wolfenet.com/jhardin PGP key ID: 0x41EA94F5
  PGP key fingerprint: A3 0C 5B C2 EF 0D 2C E5 E9 BF C8 33 A7 A9 CE 76
[This isn't a band-aid I'd endorse. If you want to fix your programs,
fix them, or better write them in a language that doesn't have those
holes. -John]
--


Post a followup to this message

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