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

[Ingram <Vail () gmx net>]

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