executable stacks, a few suggetions

Colin Plumb (colin@nyx.net)
Mon, 14 Apr 97 11:42:37 MDT

This iseems like a Good Idea, but it's trivially evadable in
programs thathave any indirect function calls.

Basically, for trampolines to work, call %eax... call %ebp have to
be allowed to work to the stack.

Now, a stack-cmashing attack relies on detailed knowledge of the
address of everything inside the executable, so we assume the
attacker knows the loaded executable image.

Consider a typicall stack frame. Locals, then saved registers,
then return address, then arguments. The buffer is in the "locals"

Let's suppose that I can find an indirect call instruction somewhere
that uses a callee-save register (%ebx, %ebp, %esi, %edi on the x86).
Then I smash the stack to put the buffer's address into the stack save
slot for that register, and smash the return address to point to
the indirect call instruction.

When the procedure exits, it will deallocate the locals (but it's
very unlikely that a signal will arrive and trash the buffer's code
in this short a time window), restore the saved registers (including
our modification)m and return to the normal code segment, which
will then make an indirect call to the buffer. BAD.

Even if we compare the pointer with the stack pointer, you could just
overflow the buffer even more and scribble the code over top of valid
stack, rather than a buffer which has been popped off.

The only way to fix *that* that I know of is to check that the code
jumped to really looks like a trampoline, and not exec("/bin/sh").

Does this make sense?