Re: A way to prevent buffer overflow exploits? (John D. Hardin)
30 Jul 1998 23:25:24 -0400

          From comp.compilers

Related articles
Re: A way to prevent buffer overflow exploits? (1998-07-30)
Re: A way to prevent buffer overflow exploits? (1998-07-31)
Re: A way to prevent buffer overflow exploits? (1998-07-31)
Re: A way to prevent buffer overflow exploits? (Toon Moene) (1998-08-02)
Re: A way to prevent buffer overflow exploits? (David L Moore) (1998-08-02)
Re: A way to prevent buffer overflow exploits? (1998-08-03)
Re: A way to prevent buffer overflow exploits? (1998-08-04)
[11 later articles]
| List of all articles for this month |

From: (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
  pgpk -a finger:// 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.