lkml.org 
[lkml]   [1997]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectAnother 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.."



\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.163 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site