>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.
If you let me put a megabyte of arbitrary data on the stack, I can
defeat your mechanism completely. I simply fill most of the overrun
data with no-op instructions with my exploit code at the end. Of course,
the no-op instructions are also return addresses that point somewhere in
the stream of no-op instructions. These instructions will have to be
chosen carefully, and they won't always work, but if you're going to align
to every eight bytes then I can probably think of some x86 code that can
be used in every four bytes to jump over anything that gets in the way.
If you let me write 1K on the stack, my probability of success is 0.1%.
Not good but certainly worth trying if I don't mind being detected.
If I can write 64K on your stack then I'll exploit successfully once every
16 tries or so.
Now, if you set up the stack so that it appeared at a random point in the
higher gigabyte, then you're talking about significantly improved security.
In fact, 99% of programs don't need more than 512 megs, so you could use
up to 2.5 gigs of address space to choose a secure stack offset, unless
something like shared libraries get in the way. Naturally this wouldn't be
the default, or programs that really do use 500 megs of memory would stop
working...
-- Microsoft Magic Line, The: n; the curve on a price-performance chart defined by the set of current shipping MS products. New MS products shift the MML upward. Competitive products that fall below the MML become unmarketable and disappear. Hence, Microsoft is always the worst marketable solution for any real problem.