It is often shown that non-executable data segemnts are possible to bypass through return-to-libc attacks. It's evident on
/bin/sh but is it also possible to invoke a remote shell?
The universal parts of an exploit are often called "shell code" because they usually do exactly that: Start a shell process and connect stdin/stdout to a network socket.
This paper may be interesting:
Sure it is possible! What about a call to
I think, if I've got this right, you're asking:
"What is the difference between a return to libc attack vs a standard buffer overflow and is an exploit involving invoking a remote shell still possible?"
The difference is subtle. First let's take a look at the stack. Avid's going to just love this piece of code:
Which is clearly vulnerable to a buffer overflow. The stack for this function should look like this:
Now, a traditional buffer overflow allows you to do this:
That's a really simple example - you overwrite the return address to point at your stack. In practice that's quite hard, so you end up using a NOP Sled which is equivalent to "aim in the right place".
Of course, all of this is defeated if that stack area is non-executable because the processor won't execute those instructions. Excellent!
Well not quite. We can't get shellcode of our own into memory to execute, but luckily there are lots of libraries in code that will do pretty much any system call. Technically, we could pick any function we liked, completely, but the most obvious choice is
When we get to libc, the stack frame is set up with the arguments said function needs, so we can do anything the function we've chosen can do, e.g. launch an instance of
This is clearly quite tough and depends on lots of things. How big is the buffer? Does it get manipulated post buffer overflow (overwriting your arguments)? Do you care about the target process (the one whose stack you just clobbered) staying up, or not? Lot's of issues practically, but theoretically it can be done.