Gains from a buffer overflow Test

I recently read a lot of things at the bottom of the computer, and I feel that it is no longer difficult to read the assembly code. So I want to combine the recent reading to make some small things to prove the knowledge in books. The first thing that comes to mind is stack-based buffer overflow attacks.
I have read a lot about the principle of the buffer overflow attack, but it is not difficult to understand it. But I 'd like to make a simple experiment myself.

Test environment: Ubuntu 6.10, kernel version: 2.6.17.10, GCC: 4.1.2 GDB: 6.4.90

The Code is as follows:

# Include <stdio. h>

Char Buf [] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x00,0x00, 0x0a, 0xff, 0x0d, 0x0e, 0x0f, 0x10, 0xe4, 0x83,0x04,0x08 ,''};


Void hack ()
{
Printf ("You have been hacked .");
}

Void unsafecopy (const char * SRC)
{
Char Dest [8];
Strcpy (DEST, Src );
}
 

Int main ()
{
Unsafecopy (BUF );
Printf ("I am not hacked .");
Return 1;
}

Objective: To make the program output "you have been hacked." by assigning a proper value to the Buf ."

According to the knowledge in the book, the idea is very simple. The strcpy () vulnerability does not check the buffer length and is passed to strcpy a data source that is too long to overwrite the return address of the unsafeco stack frame, rewrite it to the address of Hack () to achieve the goal of hack.

OK. How long should the Buf be? How should I assign values to the content? You need to use GDB to view the unsafecopy disassembly code for further determination.

(GDB) disas unsafecopy
Dump of Cycler code for function unsafecopy:

0x080483f8 <unsafecopy + 0>: Push % EBP
0x080483f9 <unsafecopy + 1>: mov % ESP, % EBP
0x080483fb <unsafecopy + 3>: Sub $0x28, % ESP

0x080483fe <unsafecopy + 6>: mov 0x8 (% EBP), % eax
0x08048401 <unsafecopy + 9>: mov % eax, 0 xffffffec (% EBP)

0x08048404 <unsafecopy + 12>: mov % GS: 0x14, % eax
0x0804840a <unsafecopy + 18>: mov % eax, 0 xfffffffc (% EBP)
0x0804840d <unsafecopy + 21>: XOR % eax, % eax

0x0804840f <unsafecopy + 23>: mov 0 xffffffec (% EBP), % eax
0x08048412 <unsafecopy + 26>: mov % eax, 0x4 (% ESP)
0x08048416 <unsafecopy + 30>: Lea 0xfffffff4 (% EBP), % eax
0x08048419 <unsafecopy + 33>: mov % eax, (% ESP)
0x0804841c <unsafecopy + 36>: Call 0x804832c <strcpy @ PLT>

0x08048421 <unsafecopy + 41>: mov 0 xfffffffc (% EBP), % eax
0x08048424 <unsafecopy + 44>: XOR % GS: 0x14, % eax
0x0804842b <unsafecopy + 51>: je 0x8048432 <unsafecopy + 58>
0x0804842d <unsafecopy + 53>: Call 0x80482fc <__stack_chk_fail @ PLT>

0x08048432 <unsafecopy + 58>: Leave
0x08048433 <unsafecopy + 59>: Ret

The assembly code above is not complex. The following information can be obtained:

1. The Dest position in the local buffer ranges from 0xfffffff4 (% EBP) to 0 xfffffffc (% EBP), that is, start from-0xc (% EBP) and end from-4 (% EBP ), the length is 8 bytes.
2. Location-4 (% EBP) stores the value of % GS: 0x14, which is described later.
3. The storage location of the returned address (EIP) is 4 (% EBP ).
4. The input parameter is stored at 8 (% EBP ).

According to the above information, the conclusion is that the Buf length is 20 bytes, which corresponds to the length from-0xc (% EBP) to 8 (% EBP) in the stack, and the last 4 bytes should be the address of Hack (): considering that strcpy will copy until the '/0' ending symbol is encountered in the source string, add a byte to the Buf to store '/0 '.

Use GDB to view the hack () entry address: 0x080483e4

Therefore, it seems that assigning a value to the Buf can achieve the goal.
Char Buf [] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0xe4, 0x83,0x04,0x08, '/0 '};

Run the command after re-compilation. The result is as follows:

Jekyll @ Ubuntu :~ $./A. Out
* ** Stack smashing detected **:./A. Out terminated
Ignore

What's going on? The previous buffer overflow attack was detected at runtime, and the program was automatically terminated.

Where is the problem? The problem lies in the two programs marked in red in the disassembly code!

In the first section, write the GS: 0x14 value to the location-4 (% EBP). Pay special attention to the position following the self-buffer.
The second segment reads the value at location-4 (% EBP) after strcpy () is executed, and compares it with the value of % GS: 0x14. If not, if strcpy has an out-of-bounds access during execution, it is redirected to _ stack_chk_fail @ PLT. I did not take a closer look at the specific operation, but it is estimated that the program is terminated after the jump.

At this time, the natural reaction is to modify the Buf assignment so that strcpy can re-write the original value of-4 (% EBP) when crossing the border. This way, when crossing the border, escape the preceding check. Check with GDB and you will know that the value of % GS: 0x14 is 0xff0a0000. Then, it seems that you can modify the Buf as follows:

Char Buf [] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x00,0x00, 0x0a, 0xff, 0x0d, 0x0e, 0x0f, 0x10, 0xe4, 0x83,0x04,0x08, '/0 '};

Compile again. Execution result:

Jekyll @ Ubuntu :~ $./A. Out
I am not hacked.

Dizzy, what happened? Although the program was not forcibly terminated, it did not execute the hack () function I expected. Where is the problem?

The problem is still in the nasty position-4 (% EBP). Let's take a look at its value: 0xff0a0000. According to the i386 architecture data storage method, in the stack, the values are 0 x, 0x00, 0x0 A, and 0 x FF respectively. The problem lies in 0x00. This is not the string Terminator '/0! Now I understand that because the Buf has to be mixed into '/0' in the middle, the subsequent characters will not be copied. Therefore, the buffer overflow attack I want to achieve is impossible.

In this case, it seems that when GCC implements the C standard library, it should take into account the potential security risks of strcpy and use such a mechanism to implement protection against buffer overflow attacks.

GCC is really tough. I cannot make such a simple test.

It is really "the end of the paper is shallow", there is a lot of distance between theory and reality, from this simple experiment, we can see that we want to use strcpy () in reality () buffer overflow attacks are not as simple as they seem. At least you have to have a lame programmer and a poor compiler to work with you.