Buffer overflow doesn't overwrite eip

[vvukotic]

Hello,

I was trying to run some sample buffer overruns and notice that the eip doesn’t get overwritten.
For example:

main(int argc, char *argv[])
{
char a[100];
strcpy(a, argv[1]);
}

Overwrites the ebp but not the eip

[user@localhost shellcode]$ ./vulnerable `perl -e 'print "A" x300'`
Segmentation fault (core dumped)
[user@localhost shellcode]$ gdb vulnerable core.14291
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
....
Loaded system supplied DSO at 0xfe0000
Core was generated by `./vulnerable AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA'.
Program terminated with signal 11, Segmentation fault.
....
#0  0x080483b1 in main (argc=Cannot access memory at address 0x41414149
) at vulnerable.c:5
5       }
(gdb) info registers eip
eip            0x80483b1        0x80483b1
(gdb) info registers ebp
ebp            0x41414141       0x41414141
(gdb)

Can someone help me understand why this happens?
Is there a way to get this examples working under FC4?

Thanks

[RedFedora]

I'll take a stab at this one. You are using the buffer overflow to over-write memory. Stack
memory in this case, I believe. However, registers don't reside in the memory. They are
"containers" inside the processor. You can't really "over-write" them.

Now, it's been a while since I did this, so I may be off here, but this is what I think has happened.
The return address for the main() function got over-written by your 'A' (0x41). This return address
got loaded into the EBP register. If I remember correctly, and I may be wrong) the EBP register
contains the pointer to where code will be executed. EIP contains a pointer to data, usually, rather
than executable code.

Anyway, the EBP register loaded 'AAAA' as the next location to find code, the processor tried to
go to that addresses and had its fingers slapped.

[vvukotic]

Hello,

thank you for answering me.

Sorry for the inaccuracy using when talking about overwriting registry, i know they ‘re not on the stack but talk as they where

Here is a sketch of the stack after the function get called:
...
EBP
Return address
str
....

The string should overwrite both the return address and the EBP. The return address cause the EIP (enhanced Instruction Pointer) to jump to the address stored in it that is in our case 0x41414141.

But I noticed it does not rewrite the return address or something similar.
I don’t know if it is because of the OS or the gcc but noticed this on FC4 and today I tested it o FC3 and saw the same.

The bad thing is that examples from “The art of Exploitation” & “Shellcoders’ Handbook” want work.
The good thing is that if true FC would probably be much harder to run shellcode on and so much secure
(But I would still like to have those examples work on FC4)

Later on I installed slackware 10.0 on VMware and notice that both the return address were overwritten, as it should be. So both eip and ebp contained the value 0x4141414141.

root@localhost:~#  ./vulnerable "perl  -e  "print "A"x300';" 

Segmentation fault (core dunped)



root@localhost:~# gdb vulnerable c:ore GNU gdb 6.1.1

Copyright 2004 Free Softuare Foundation,  Inc.

GDB is free...

This GDB was configured as "i4B6-slackware-linujt"... Using host libthreaddb library "/lib/libthreaddb .so.l".

Core was generated by    ./vulnerable AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Progran teminated with signal 11 r  Segnentation fault.

Reading synbols fron /lib/libc.so.6...done.

Loaded synbols for /lib/libc.so.6

Reading synbols fron /lib/ld-linux.so.2...done.

Loaded syibols for /lib/ld-linux.so.2

#0    0x41414141 in  ?? ()

(gdb)  info registers eip

eip                     0x41414141             0x41414141

(gdb)  info registers ebp

ebp                     0x41414141             0x41414141

(gdb)