Crispin Cowan wrote:
> I presume that what you're doing here is to mark the library pages
> non-executable, and then make them executable when you get a page fault due to
> some code trying to make a library call. If so, how do you distinguish between
> legitmate calls into the library, and bogus calls made by a buffer overflow?
No, because there is no exec/noexec flag on x86 architecture - otherwise
the whole thing would be trivial.
I map a sort of ´zombie´ or ´ghost´ libc into the RSX address space,
marking those pages as PROT_NONE. I also map a regular copy of libc at
some other location.
There are further transition handlers in the gp() and pf() trap code
handling the segment transitions between ´normal´ code and ´libc´ code
(the mentioned ret/call/jmp emulation routines).
> "ret-into-libc" is just a common name for the technique. It is not technically
> precise. The general case is to change a function return address so that it
> jumps to code that does "exec(sh)". The intructions that do this don't have to
> be in libc, and don't have to be in a library, they can be in the program's main
> executable body. It's just convenient for the attacker to use libc, because libc
> necessarily has "exec(sh)" in it, and most programs link to libc.
Ok but I´m talking only about dynamically linked libc.
> > So now assume we doesn't link the libc-plt to the real libc location -
>
> Same effect: you deny the attacker access to the libc code body, forcing them to
> look elsewhere for a fairly common sequence of a half dozen bytes in an
> executable page.
Hm, I´m not convinced that this code is so common. One must look for a
sequence similar to mov value, %ebx; mov SYSCALL, %eax; int 0x80; in
order to do something dangerous after overflowing a stack buffer.
I think that some level of randomization in the libc location and the
plt linking code would provide a simple (but not complete) defense
against simple jump-into-system()-plt and similar attack.
Paul Starzetz.
