Another way to reduce risk of executable stack?

Oliver Xymoron (oxymoron@waste.org)
Fri, 20 Jun 1997 14:11:29 -0500 (CDT)

My understanding of executable stack exploits is that the attack must
know the absolute position on the stack to set up a return pointer to its
own code. This is because the return is an absolute jump rather than a
relative one. This is not a problem for most exploits because most
programs don't recurse - they are at a repeatable depth in the stack
when the buffer overrun occurs.

However, if the kernel created processes so the stack were to start at a
random (aligned) offset from the top of the virtual memory address space
rather than consistently at the top, an exploit would no longer be able to
reliably guess where to jump to. If you allow a megabyte out of 3 gigs of
address space for slop, you have 128k 8-byte aligned possible starting
points for the stack and about a .001% chance for an exploit to work on a
given run.

I've tried hacking my kernel to decrease stack_top in setup_arg_pages
(fs/exec.c) but none of init's children seem to run properly (though init
seems to be ok). What am I missing?

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."