Re: A way to prevent buffer overflow exploits?

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

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