Executable memory: further programs that fail

[Behdad Esfahbod]

I can't completely understand what you are saying, if exec-shield
is good, or not.  BTW, that scanning that you say is easy to do,
is not so easy for a couple of reasons:

  * You need to do that in an exploit code, which most of the
time is limited in length, and should not have any null bytes.

  * Scanning through 4GB is not any fast.

  * What you are missing:  Reading an invalid location in VM
would cause a segfault.

You most probably need your IP in your exploit.  What people do
is to write a few bytes of code somewhere in memory, and call the
code, and pop IP from stack.  With randomized VM, you don't know
where to put your code.  Even if you find one, with non-exec heap
and non-write code segments, you can't both write your code
somewhere, AND call it.

If a hole is already in a library function, which you like to
call, again more than the above reasons, the ascii shielded
property prevents you.

As the least, exec-shield stuff is very very useful to protect
possible holes in suid binaries.

behdad

PS.  I admit this thread is completely off-topic.  Hope it's the
last post.

On Tue, 25 Nov 2003, Tim Daly wrote:

> Gordon,
>
> The library code is shared. I can trivially search memory for a pattern
> that matches the routine I want to call. The memory can be read. The
> pattern is known beforehand since the binaries are widely distributed.
> The pattern match is a small loop.
>
> The typical buffer overflow, especially inline buffers, simply overwrites
> inline instructions. I've seen a buffer overflow in the several hundred K
> range of code. You can statically link the library code in the exploit given
> that much code in the overflow. Forcing code areas to be read-only would
> disallow inline buffers and require malloced buffers.
>
> I also understand the stack-execute issue. I can think of ways to exploit
> the system by stomping on return addresses in stack frames and even playing
> spaghetti-stack continuation games to leave my exploit around. All of these
> I can explain to my students.
>
> These are all good changes. I've just drawn a complete blank about how
> to explain fragmenting memory, especially after I've explained how and why
> segment registers exist.
>
> Tim