[7462] in bugtraq
A way to prevent buffer overflow exploits? (was: "Any user can
daemon@ATHENA.MIT.EDU (John D. Hardin)
Wed Jul 29 15:25:10 1998
Date: Wed, 29 Jul 1998 09:13:26 -0700
Reply-To: "John D. Hardin" <jhardin@WOLFENET.COM>
From: "John D. Hardin" <jhardin@WOLFENET.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199807282042.NAA02140@passer.osg.gov.bc.ca>
On Tue, 28 Jul 1998, Cy Schubert wrote:
> What makes MVS (and VM) so impervious to attack is that the S/390
> hardware doesn't rely on a stack, making effective buffer overruns
> considerably more difficult. (A little off topic :)
(to continue the topic drift, and throw some ideas into the pot...)
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?
Or how about allocating space for all local variables from the system heap
automatically and transparently rather than placing them on the stack?
Or how about automatically allocating space just for local strings? This
would take care of buffer overflows with minimal impact, wouldn't it?
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 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
-----------------------------------------------------------------------
Your mouse has moved. Windows NT must be restarted for the change
to take effect. Reboot now? [ OK ]
-----------------------------------------------------------------------
88 days until Daylight Savings Time ends
