the possibility of jumping back to code in an exploited program

[Jonas Yorg <jonasyorg () gmail com>]

So I heard somewhere once that supposedly a buffer-overflowing program
can jump back into the code it's exploiting in order to call some
system call (after setting up the appropriate stack/register
environment I would suppose). I think that whoever I read heard from
was maybe thinking of return to libc type exploits where you jump to
some libc wrapper for a system call.  Anyway my question is this (for
both linux and windows, but mainly linux for now): Is it possible to
directly jump back to code in the program you exploited?

I've been running some tests with linux which lead me to believe it's
not possible, but I realize that I don't know for sure that it isn't
my coding mistake. So here's the setup.  I've got a simple program
with the standard strcpy type overflow of the stack return
address...(well except that I'm using memcpy during development so I
don't have to be all clever about restricted characters until I get it
working ;) So my vulnerable server has a socket, bind, listen, and
accept call in that order before it waits for input (obviously).  So
I'm going to use bind for this example because I've also been using
kdb to see what things look like in the kernel depending on the attack
(that's the research :) and bind is less likely to be called by
something else while I'm messing around...So if I overflow the buffer
with the libc address for bind (as found by "disassemble bind" from in
gdb) it jumps there fine and picks up execution. However, if I set the
address to the bind call in my main program for some reason it always
jumps to 0x3fbf8.  I know that this value doesn't mean anything in and
of itself but here's what I learned about it...right before the ret
instruction after the leave has been executed %ebp is set to 0x3fbf8
and looking at memory I can confirm that it is what is on the stack
immediately lower than my ret address... however %esp IS pointing to
my desired return address at the time that the ret is executed. So in
this case I would have said that maybe the %esp pointer is confuse or
something which makes the ret pop the previous value off the stack and
jump to it instead of the one that gdb says that %esp is pointing to
(or gdb is confused I don't know)

So that would be a good theory except that I tried to get around that
by exploiting the stack as normal, and then putting a jump to my
desired place in the original code as the first thing it executes
right after the nop sled (hehe primitive exploit, but I'm just
learning :) Because I wasn't sure at the time how to do a force my
inline assembly to compile it as a long jump, or how to write a long
jump in strait hex to put into the sent overflow I did the following. 
I put the address I wanted to jump to into %eax and then did a jmp
*%eax (which I tested as working with a different address before doing
it in the exploit).  Well I get past the nops, I execute the
instructions to movl the address into eax, I verify that it's in eax
and then I execute the instruction to jmp *%eax.  But wonder of all
wonders it says "Cannot access memory at address 0x3fbf8"!!! So this
time I have no excuse for where that magic number cam from except that
I dont understand what's going on.

My possible theory is that this has something to do with jumping from
the stack to the normal code and that their memory pages are marked
differently. I.e. here's what I get from kdb

vm 0xbfff18c  (the esp at the time of the libc wrapper int 0x80)
<cut> 
vm_flags:       SHARED MAYEXEC DENYWRITE EXECUTABLE IO
<cut>

vm 0x08049812 (the place in the the vulnerable server that calls the
bind libc wrapper. Where I want to jump to)
<cut>
vm_flags:       READ WRITE MAYSHARE SHM IO
<cut>

but basically that's just my uneducated guess based on reading
somewhere that you have to have some privileges to jmp between certain
pages...

any one know if this is right or not?  If so in general is it possible
to do this sort of jump if the program was running as root, or not at
all (I'm not running it as root)

Thanks for your help and suggestions!

Jonas