Re: Announcing RSX - non exec stack/heap module

[Paul Starzetz <paul () starzetz de>]

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.