the possibility of jumping back to code in an exploited program

From: Jonas Yorg (jonasyorg_at_gmail.com)
Date: 06/15/05

  • Next message: Syversen, Jason M (US SSA): "RE: tools for searching potential BO in binary code"
    Date: Tue, 14 Jun 2005 19:20:44 -0500
    To: vuln-dev@securityfocus.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


  • Next message: Syversen, Jason M (US SSA): "RE: tools for searching potential BO in binary code"

    Relevant Pages

    • RE: the possibility of jumping back to code in an exploited program
      ... > was maybe thinking of return to libc type exploits where you jump to ... necessarily need to overwrite the whole EIP on the stack. ... > I'm going to use bind for this example because I've also been using ... > of itself but here's what I learned about it...right before the ret ...
      (Vuln-Dev)
    • Re: hop on/hop off animated objects
      ... working the meaning of 'jump' has been interpreted in two different ... bind to viewpoint just changes your 'home', jump true means go to ...
      (comp.lang.vrml)
    • Re: Priests having a tought time
      ... must jump through? ... "whatsoever ye bind on earth is bound in Heaven." ...
      (alt.religion.christian.roman-catholic)
    • Re: compiler generated output
      ... > compiler to generate code which only uses 386 instruction). ... > Thus, while replacing mov/and with movzx, the jump is still there. ... mov eax, ... Software Optimization Guide for ...
      (comp.lang.asm.x86)
    • Re: Which assembler can handle the BIG stuff ?
      ... >> shl eax, 2; Byte offset from start of TABLE ... Jump tables as defined in "ancient code" were very efficient for the ... most code using "jump tables" call the pointers instead of jmp ax or jmp eax. ... ASM programs, and in fact would be a sign of incpometent programming skills if a ...
      (alt.lang.asm)