Buffer Overflow
 

Hello!

I am using fedora core with compiler
gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1

I am trying to write a buffer overwrite program(As my assignment). In that,
I am filling buffer with 'A's. This overflows fine, but the content of the IP register is
shown as something else then '4141414141414141' (Which is Ascii for 'A's.)
BP is showing '4141414141414141' fine.

Is this a new feature of gcc? How to circumvent it?

Thanx

You will need to give the program.

Without seeing the program it sounds like one of two possibilities:
1) the overflow is not stretching far enough along the stack - if you are trying to be precise realize that GCC 3.something added padding to the stack to prevent {one,five} byte overwrites; if you are a following some tutorial online, it might not cover this.
2) the program has not returned from the function and, thus, eip has not changed, yet.

Those are just guesses though, I would need to see the code for more of an idea.

Ya, I am trying to follow online tutorial,

http://infosecwriters.com/texts.php?op=display&id=134

following is the code and trace. notice that I am overrunning by 12 bytes, and precise
overrunning is not even giving segmentation fault.

Thanks


#include <stdio.h>
int main(int argc, char **argv)
{
char buff[512];
if(argc < 2)
{
printf("Usage: %s \n", argv[0]);
exit(0);
}
strcpy(buff, argv[1]);
printf("Your name: %s\n", buff);
return 0;
}

$ /a.out `perl -e'print "A" x 524'`
Your name: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)
$ gdb -c core.2349
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
...
Program terminated with signal 11, Segmentation fault.
#0 0x008e6703 in ?? ()
(gdb) info reg
eax 0xf6 246
ecx 0xa04da0 10505632
edx 0x218 536
ebx 0xa06998 10512792
esp 0xbff52920 0xbff52920
ebp 0x41414141 0x41414141
esi 0xbff529a5 -1074452059
edi 0xbff529b0 -1074452048
eip 0x8e6703 0x8e6703
eflags 0x10286 66182
cs 0x23 35

Yes, your problem is definitely to do with stack frame padding. Open up GDB and run the command `disass main', you are looking for:

This is the main function setting up it's stack frame, above the stack frame of it's parent. You will notice that on my system GCC-3.3.1 has created a stack frame that is 552 bytes. You need to take this into account.

As you can see you have managed to overwrite the saved %ebp value, but have not reached %eip. Here is the output for you of two invocations:

The general lesson to learn from this is to always review what the compiler has created. It is very difficult to understand this properly without some base understanding of how memory works and assembly code (you do not need to be able to write it, but approximate reading of it is useful). The other thing is, when you are looking to overwrite the %eip via a simple technique such as this then you should open up the calling function and find the `return location' (as in, what value the saved %eip will contain). Using this `return location' you can take a view of memory and find the exact address that the system intends to pop back into the instruction pointer. From there it is simple to work out how much you need to write. I took a glance at the tutorial you are studying, and it does not seem to cover scenarios such as this -- you should maybe look for a more general tutorial, one without the assumptions made.

Okay, here is something simple to try. All of this is not necessary, but it should make it easy to highlight where the issue lies. Grab yourself a breakpoint just after the strcpy call:

Run the program filling the buffer perfectly (ie, 512 x `A'). After it breaks get the value of %ebp:

Note that down, and then we will view a chunk of memory, with %ebp sitting in the middle:

Now, you can see the approaching army of A's headed for %ebp. The address that you are after is %ebp+4 (0x4002e91e in my case).

I hope I have kept that as clear as possible.

Have you read....."Smashing the stack for fun and profit"??
do a google.......it should help in your understanding of the Stack overflow.

Well,

I completed writing program and it turned out that it works fine when I compile it on RH7 and RH9.0 and then run on my machine. When I execute a buffer exploit compiled on my machine, It breaks on the ret instruction.

This makes me guess, that there is indeed some new trick in the GCC that shipped with fedora core.

Thanx for replies.