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: Re: A way to prevent buffer overflow exploits? (was: "Any user

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

Brett Glass (brettLARIAT.ORG)
Wed, 29 Jul 1998 16:41:41 -0600 

At 09:13 AM 7/29/98 -0700, John D. Hardin wrote:

>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