I pulled his from the security forum so here it goes:

Sorry for being so indescriptive. I created a fedora core 2 system to play around on. I created a program in C listed here:

void return_input(void)
{
char array[30];

gets (array);
printf("%s\n", array);

}

main()
{
return_input();
return 0;

Obviously, there is a glaring overflow vulnerability within the return_input function. I compiled the program with gcc using the -mpreferred-stack-boundary=2 -ggdb option listed here:

[neophyte@localhost overflow_pg19]$ gcc -mpreferred-stack-boundary=2 -ggdb overflow.c

/tmp/ccsyJRjA.o(.text+0xb): In function `return_input':
/home/neophyte/code/shellcoders_handbook/overflow_pg19/overflow.c:5: warning: the `gets' function is dangerous and should not be used.

[neophyte@localhost overflow_pg19]$ ./overflow AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation Fault (core dumped)

then:

[neophyte@localhost overflow_pg19]$ gdb overflow core.xxxxxx

info registers

and here we have it: ebp is x41414141 (cap A's)
and unfortunately eip is x80483c8

it seems no matter what I do I can not override eip. There is something obviously limiting this from happening and I'm not sure what it is. Any help would be greatly appreciated. Thanks again!

-Neophytic

I'm not sure why you would want to do this :glares:, but you can't "overwrite" a register exactly. I haven't done any of this stuff in a while, so don't quote me on any of this, but basically an overflow that executes arbitrary code has to do with the fact that the stack grows up in memory while the data memory(I think there is a better term for this) grows down.. or something I may have confused up with down.

When a program calls a function, it "push"es the return address onto the stack. When the function is done executing, it does "ret" which takes what should now be the return address(since everything inside the function that was put on the stack has been taken off, like other inner function calls) and places that address in the eip, instruction pointer. Now if you can overwrite the stack with your buffer overflow, you can get the ret to go to wherever you want. However, if it goes to some place thats not an instruction, or some garbage some where (like what's probably at address "0x41414141", then you'll get a segmentation fault and the eip will be put some place safe by the kernel?

I really have no idea what I'm talking about, but the gist of it is that it looks like the execution of the "ret" realizes maybe that 0x41414141, maybe isn't in addressable memory, nor executable memory and segmentation faults. What you should do, is walk through the program with gdb using the next i or whatever to step through it instruction by instruction.

I can't think of a legitimate reason to do this stuff. You can compile with the -s switch to make gcc spit out the assembly code for your program. Something like gcc -s myprog.c will spit out a myprog.s file that contains the assembly code. Looking through that should give some insight into how overflow vulnerabilities work.

I have no desire to do anything malicious with the information. I am just facinated at how things work. I will check out the gdb stepping. If I figure it out I will let you know. It is able to be done on older versions just not newer versions. Thanks again

-Neo

Fedora core and some newer versions of linux come with stack protections. Fedora especifically has Exec shield by default. Common technicas just wont do due to the fact exec shield will randomize an protect eip from being overwritten. If its your firts time you are trying to exploit a program i recommend you, dissable exec shield or get another distro like slackware 9 or mandrake 9.1

By the way, learning to overflow buffers is probably not the best first step to a security career. It's much better to learn what you're defending and why first, along with common defense techniques. Learning the attacks is fine, but knowing how to attack a system doesn't necessarily teach you how to defend it.

Not to mention, if you would have studied defense techniques you would have already known about stack protection and you would have realized why your exploit was failing.

As Freakz pointed, Fedora has a stack protection in the kernel (exec-shield) so your exploits wont work, you ret address will not overwrite.. So if you want to use the fedora for your training you have to disable the exec-shield, here are two easy ways :
"sysctl -w kernel.exec-shield=0" or "echo 0 > /proc/sys/kernel/exec-shield" this changes are on the fly, you could exploit the example now.
Hope it helps, and keep learning