Messages in this thread | | | Date | Fri, 20 Jun 1997 14:11:29 -0500 (CDT) | From | Oliver Xymoron <> | Subject | Another way to reduce risk of executable stack? |
| |
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.."
| |