Advanced Return to libc Exploits

The sample vulnerable code follows:
void f2(char * buf)
{
printf(buf); // format bug here
some_libc_function();
}
void f1(char * user_controlled)
{
char buf[1024];
buf[0] = 0;
strncat(buf, user_controlled, sizeof(buf)-1);
f2(buf);
}
Suppose f1() is being called. With the help of a malicious format
string we can alter some_libc_function's GOT entry so that it contains the
address of the following piece of code:
addl $imm, %esp
ret
that is, some epilogue of a function. In such case, when some_libc_function
is called, the "addl $imm, %esp" instruction will alter %esp. If we choose
an epilogue with a proper $imm, %esp will point within "buf" variable,
whose content is user controlled. From this moment on, the situation looks
just like in case of a stack buffer overflow. We can chain functions, use
ret-into-dl etc.
Another case: a stack buffer overflow by a single byte. Such
overflow nullifies the least significant byte of a saved frame pointer.
After the second function return, an attacker has a fair chance to gain
full control over the stack, which enables him to use all the presented
techniques.
----[ 7.3 - Other non-exec solutions
I am aware of two other solutions, which make all data areas
non-executable on Linux i386. The first one is RSX [10]. However, this
solution does not implement stack nor libraries base randomization, so
techniques described in chapter 3 are sufficient to chain multiple function
calls.
Some additional effort must be invested if we want to execute
arbitrary code. On RSX, one is not allowed to execute code placed in a
writable memory area, so the mmap(...PROT_READ|PROT_WRITE|PROT_EXEC) trick
does not work. But any non-exec scheme must allow to execute code from
shared libraries. In RSX case, it is enough to mmap(...PROT_READ|PROT_EXEC)
a file containing a shellcode. In case of a remote exploit, the function
chaining allows us to even create such a file first.
The second solution, kNoX [11], is very similar to RSX. Additionally,
it mmaps all libraries at addresses starting at 0x00110000 (just like in
the case of Solar's patch). As mentioned at the end of 3.4, this protection
is insufficient as well.