|Re: A way to prevent buffer overflow exploits? email@example.com (1998-07-30)|
|Re: A way to prevent buffer overflow exploits? firstname.lastname@example.org (1998-07-31)|
|Re: A way to prevent buffer overflow exploits? email@example.com (1998-07-31)|
|Re: A way to prevent buffer overflow exploits? firstname.lastname@example.org (Toon Moene) (1998-08-02)|
|Re: A way to prevent buffer overflow exploits? email@example.com (David L Moore) (1998-08-02)|
|Re: A way to prevent buffer overflow exploits? firstname.lastname@example.org (1998-08-03)|
|Re: A way to prevent buffer overflow exploits? email@example.com.OZ.AU (1998-08-04)|
|[11 later articles]|
|From:||firstname.lastname@example.org (John D. Hardin)|
|Date:||30 Jul 1998 23:25:24 -0400|
|Organization:||Wolfe Internet Access, L.L.C.|
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
> >Or how about allocating space for all local variables from the system
> >heap automatically and transparently rather than placing them on the
> 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
> >Granted, fixing the applications is the better long-term solution, but
> >these might be ways to buy time to do the auditing and correction.
John Hardin KA7OHZ email@example.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
Return to the
Search the comp.compilers archives again.