Re: Unexecutable Stack / Buffer Overflow Exploits...

[(no name)]

On Thu, Dec 30, 1999 at 02:11:00PM -0800, Steve VanDevender wrote:
> Richard Zidlicky writes:
>  > On Wed, Dec 29, 1999 at 11:27:33AM -0800, Dan Hollis wrote:
>  > > And I dont see any reason why this cant be a kernel compile option. If you
>  > > dont like it, dont enable it. I suspect the vast majority of users will
>  > > enable it though. I know I would.
>  > 
>  > Why not even make it a runtime option, programs get nonexec stack by default
>  > and could do some mmap or other syscall if they realy needed the stack or
>  > some portion of it executable.
>  > Are there any technical difficulties I am overlooking?
> 
> Yeah.  Exploit code that now includes exec("/bin/sh") will
> simply precede it with make_stack_executable() if it's
> runtime-selectable.

when you can do that then you have already succesfully broken in, no need
to do it again.

IMHO a scheme like this would allow keeping most of the unexecutable stack
benefits while removing the (supposedly bloated AI) code to guess trampolines 
from kernel.
Might even make the 'simulate a trampolin' attack useless - it doesn't buy the 
attacker anything unless he can also force the program to do make_stack_executable(). 
Obviously if he can do that than he already found some other exploit.

So why not simply make the stack unexecutable by default and allow the few
special applications to make portions of it executable again? No compatibility
problems with new trampolin types, no kernel magic, no guarantees but a little 
step to more finegrained control.

Bye
Richard