controlling ebp/eip of a frame, does it always lead to possible code execution?

From: Ingram (Vail_at_gmx.net)
Date: 09/18/03

  • Next message: Alexander E. Cuttergo: "Re: OpenSSH Vulnerability" 
    Date: Thu, 18 Sep 2003 16:49:26 +0200 (MEST)
To: vuln-dev@securityfocus.com

    hello,

    again i have a little question about buffer overflows,
    that i could not figure out by myself.

    If i can control what is written to ebp and eip, i thought
    that this always would be enough to execute shellcode,
    ...it seems not:

    >./exploit
    Segmentation fault (core dumped)
    >gdb ./myprog ./myprog.core

    .
    .
    .
    (gdb) bt
    #0 0x280e8cfa in vfprintf () from /usr/lib/libc.so.4
    #1 0x280da116 in sprintf () from /usr/lib/libc.so.4
    #2 0x8048eda in main ()
    #3 0x41414141 in ?? ()
    Cannot access memory at address 0x42424242.
    (gdb) f 3
    #3 0x41414141 in ?? ()
    (gdb) i reg
    eax 0x0 0
    ecx 0xffffffff -1
    edx 0x280e8c4c 672042060
    ebx 0x3 3
    esp 0xbfbfec48 0xbfbfec48
    ebp 0x42424242 0x42424242 <---- defined by me
    esi 0xbfbff7ac -1077938260
    edi 0xbfbff7bc -1077938244
    eip 0x41414141 0x41414141 <---- defined by me
    eflags 0x286 646
    cs 0x1f 31
    ss 0x2f 47
    ds 0x2f 47
    es 0x2f 47
    fs 0x2f 47
    gs 0x2f 47

    Now, i seek my nops:
    (gdb)x/2000x $esp
    .
    .
    .
    0xbfbff438: 0x90909090 0x90909090 0x90909090 0x90909090
    0xbfbff448: 0x90909090 0x90909090 0x90909090 0x90909090
    0xbfbff458: 0x90909090 0x90909090 0x90909090 0x90909090
    0xbfbff468: 0x90909090 0x90909090 0x90909090 0x90909090
    .
    .
    .

    and finally replace the 0x41414141 and 0x42424242 with
    a valid address (0xbfbff448) and execute the exploit again:

    ./exploit_with_real_addr
    (gdb) bt
    #0 0x280e8cfa in vfprintf () from /usr/lib/libc.so.4
    #1 0x280da116 in sprintf () from /usr/lib/libc.so.4
    #2 0x8048eda in main ()
    #3 0xbfbff448 in ?? ()
    #4 0x90909090 in ?? () <---- a new frame ? Why ?
    Cannot access memory at address 0x90909090.
    (gdb) f 3
    #3 0xbfbff448 in ?? ()
    (gdb) i reg
    eax 0x0 0
    ecx 0xffffffff -1
    edx 0x280e8c4c 672042060
    ebx 0x3 3
    esp 0xbfbfec48 0xbfbfec48
    ebp 0xbfbff448 0xbfbff448 <--- it worked !?
    esi 0xbfbff7ac -1077938260
    edi 0xbfbff7bc -1077938244
    eip 0xbfbff448 0xbfbff448 <--- it worked !?
    eflags 0x286 646
    cs 0x1f 31
    ss 0x2f 47
    ds 0x2f 47
    es 0x2f 47
    fs 0x2f 47
    gs 0x2f 47
    (gdb) x 0xbfbff448
    0xbfbff448: 0x90909090 <--- still points to NOP
    (gdb) x/10i $eip
    0xbfbff448: nop
    0xbfbff449: nop
    0xbfbff44a: nop
    0xbfbff44b: nop
    0xbfbff44c: nop
    0xbfbff44d: nop
    0xbfbff44e: nop
    0xbfbff44f: nop
    0xbfbff450: nop
    0xbfbff451: nop
    (gdb) x/10i $ebp
    0xbfbff448: nop
    0xbfbff449: nop
    0xbfbff44a: nop
    0xbfbff44b: nop
    0xbfbff44c: nop
    0xbfbff44d: nop
    0xbfbff44e: nop
    0xbfbff44f: nop
    0xbfbff450: nop
    0xbfbff451: nop

    Hmmm, here i am lost. I thought, if i can control the flow, and replace
    eip/ebp with valid addresses, that point to my nop space, my shellcode
    should get executed... what is happening here!?

    Here some additional info:

    (gdb) bt
    #0 0x280e8cfa in vfprintf () from /usr/lib/libc.so.4
    #1 0x280da116 in sprintf () from /usr/lib/libc.so.4
    #2 0x8048eda in main ()
    #3 0xbfbff448 in ?? ()
    #4 0x90909090 in ?? ()
    Cannot access memory at address 0x90909090.
    (gdb) f 4
    #4 0x90909090 in ?? ()
    (gdb) i reg
    eax 0x90909090 -1869574000
    ecx 0x90909090 -1869574000
    edx 0x90909090 -1869574000
    ebx 0x90909090 -1869574000
    esp 0xbfbff434 0xbfbff434
    ebp 0x90909090 0x90909090
    esi 0x90909090 -1869574000
    edi 0x90909090 -1869574000
    eip 0x90909090 0x90909090
    eflags 0x90909090 -1869574000
    cs 0x90909090 -1869574000
    ss 0x90909090 -1869574000
    ds 0x90909090 -1869574000
    es 0x90909090 -1869574000
    fs 0x90909090 -1869574000
    gs 0x90909090 -1869574000
    (gdb) x/10i $esp
    0xbfbff434: nop
    0xbfbff435: nop
    0xbfbff436: nop
    0xbfbff437: nop
    0xbfbff438: nop
    0xbfbff439: nop
    0xbfbff43a: nop
    0xbfbff43b: nop
    0xbfbff43c: nop
    0xbfbff43d: nop
    (gdb) x 0xbfbff434
    0xbfbff434: nop

    i also tried to replace the suddenly existing eip/ebp of frame 4,
    but after doing that i just "open" another frame like this...

    kind regards & thanks in advantage
    Ingram 

    -- 
+++ GMX - die erste Adresse für Mail, Message, More! +++
Getestet von Stiftung Warentest: GMX FreeMail (GUT), GMX ProMail (GUT)
(Heft 9/03 - 23 e-mail-Tarife: 6 gut, 12 befriedigend, 5 ausreichend)
Jetzt selbst kostenlos testen: http://www.gmx.net
  • Next message: Alexander E. Cuttergo: "Re: OpenSSH Vulnerability"

    Relevant Pages