OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 3rd quarter (Jul-Sep) 1998: A way to prevent buffer overflow exploits? (was: "Any user can

A way to prevent buffer overflow exploits? (was: "Any user can

John D. Hardin (jhardinWOLFENET.COM)
Wed, 29 Jul 1998 09:13:26 -0700

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                               jhardinwolfenet.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