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

From: deepcode . (pondermate_at_hotmail.com)
Date: 09/18/03

  • Next message: Ryan Veety: "Re: OpenSSH Vulnerability" 
    To: Vail@gmx.net, vuln-dev@securityfocus.com
Date: Thu, 18 Sep 2003 13:38:50 -0300

    By the looks of it, you are doing everything right. Your overwritten return
    address points
    directly to your nop's. The shellcode should be executed.

    What OS are you on, you may have aditional stack protections on the system
    to prevent
    standard overflows, particularly redhat 9 (shrike), which i'm using now,
    will prevent this: not
    sure exactly how yet ...

    If anyone has any info on shrikes new protection mechanism, feel free to
    reply.

    >From: Ingram <Vail@gmx.net>
    >To: vuln-dev@securityfocus.com
    >Subject: controlling ebp/eip of a frame, does it always lead to possible
    >code execution?
    >Date: Thu, 18 Sep 2003 16:49:26 +0200 (MEST)
    >
    >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
    >

    _________________________________________________________________
    Help STOP SPAM with the new MSN 8 and get 2 months FREE*
    http://join.msn.com/?page=features/junkmail

  • Next message: Ryan Veety: "Re: OpenSSH Vulnerability"

    Relevant Pages