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.
This archive was generated by hypermail 2b30 : Wed Jun 13 2001 - 12:37:59 PDT