Messages in this thread | | | Date | Mon, 14 Apr 97 11:42:37 MDT | From | (Colin Plumb) | Subject | executable stacks, a few suggetions |
| |
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" range.
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? -- -Colin
| |