Differences
This shows you the differences between two versions of the page.
|
cns:labs:lab-08 [2020/12/07 16:15] mihai.dumitru2201 [4. ROP: Functions chain] |
cns:labs:lab-08 [2021/12/14 13:28] (current) razvan.deaconescu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Lab 08 - Return Oriented Programming ====== | + | ====== Lab 08 - Return-Oriented Programming ====== |
| ===== Introduction ===== | ===== Introduction ===== | ||
| Line 263: | Line 263: | ||
| * As usual, we have to identify the overflowed buffer ''offset'' where the return address starts. We can do this using the ''peda'' ''pattc'' and ''patto'' commands as in the previous [[http://ocw.cs.pub.ro/courses/cns/labs/lab-06#phase_2finding_the_vulnerability|labs]]. | * As usual, we have to identify the overflowed buffer ''offset'' where the return address starts. We can do this using the ''peda'' ''pattc'' and ''patto'' commands as in the previous [[http://ocw.cs.pub.ro/courses/cns/labs/lab-06#phase_2finding_the_vulnerability|labs]]. | ||
| * The complete exploit can be found in ''00-tutorial-2-ret2libc/solution.py'' | * The complete exploit can be found in ''00-tutorial-2-ret2libc/solution.py'' | ||
| - | |||
| - | </code> | ||
| ==== 3. ROP: Find the buffer ==== | ==== 3. ROP: Find the buffer ==== | ||
| Line 294: | Line 292: | ||
| <note tip> | <note tip> | ||
| The buffer address is stored in a register when ''ret'' is executed. | The buffer address is stored in a register when ''ret'' is executed. | ||
| + | |||
| + | There is no need for a memory disclosure / information leak of the buffer address. **You can find a gadget that jumps / calls that register.** | ||
| Use ''%%ropsearch ... libc%%''. Instead of ''%%...%%'' place the instructions you search. | Use ''%%ropsearch ... libc%%''. Instead of ''%%...%%'' place the instructions you search. | ||
| Line 306: | Line 306: | ||
| io = process(["./ropbuf", payload]) # Run ./ropbuf using payload as command line argument. | io = process(["./ropbuf", payload]) # Run ./ropbuf using payload as command line argument. | ||
| </code> | </code> | ||
| + | </note> | ||
| + | |||
| + | <note important> | ||
| + | You can't send NUL-bytes as part of command line arguments. When constructing the payload, use ''%%pack(...).strip(b\"x00")%%''. | ||
| </note> | </note> | ||
| Line 325: | Line 329: | ||
| Now let's move to a more practical example by chaining useful ''libc'' functions. | Now let's move to a more practical example by chaining useful ''libc'' functions. | ||
| - | Take a look at ''roplibc.c''. We can see that we have a buffer overflow on ''buf'' and a global, unused ''gbuf''. | + | Take a look at ''03-roplibc/roplibc.c''. We can see that we have a buffer overflow on ''buf'' and a global, unused ''gbuf''. |
| * The stack is not executable so, at the first sight, we cannot put our shellcode neither in ''buf'', nor in ''gbuf''. But what if we manage to call (jump to) **mprotect** over the memory area where we store the shellcode, and make it executable? | * The stack is not executable so, at the first sight, we cannot put our shellcode neither in ''buf'', nor in ''gbuf''. But what if we manage to call (jump to) **mprotect** over the memory area where we store the shellcode, and make it executable? | ||
| * Furthermore, given the fact that ''gbuf'' is larger than ''buf'', we might want to put our shellcode there. But how do we do this when the only ''read'' call is on ''buf''? In this case, we will also want to call (jump to) **read** in our exploit payload. | * Furthermore, given the fact that ''gbuf'' is larger than ''buf'', we might want to put our shellcode there. But how do we do this when the only ''read'' call is on ''buf''? In this case, we will also want to call (jump to) **read** in our exploit payload. | ||
| * A possible ROP chain (that will start from the overwritten return address from ''buf'') for the described attack will look something like below. The return addresses in the ROP chain are highlighted with red and the function parameters with green. | * A possible ROP chain (that will start from the overwritten return address from ''buf'') for the described attack will look something like below. The return addresses in the ROP chain are highlighted with red and the function parameters with green. | ||
| - | **[<color red>pop rdi;ret</color>][<color green>fd=0</color>][<color red>pop rsi;ret</color>][<color green>gbuf</color>][<color red>pop rdx;ret</color>][<color green>shellcode_len</color>][read_addr] | ||
| + | **[<color red>pop rdi;ret</color>][<color green>fd=0</color>][<color red>pop rsi;ret</color>][<color green>gbuf</color>][<color red>pop rdx;ret</color>][<color green>shellcode_len</color>][read_addr]** | ||
| + | |||
| + | **[<color red>pop rdi;ret</color>][<color green>page</color>][<color red>pop rsi;ret</color>][<color green>page_size</color>] [<color red>pop rdx;ret</color>][<color green>mp3</color>][mprotect_addr]** | ||
| - | [<color red>pop rdi;ret</color>][<color green>mp1</color>][<color red>pop rsi;ret</color>]][<color green>mp2</color>] [<color red>pop rdx;ret</color>][<color green>mp3</color>][mprotect_addr][gbuf_addr]** | + | **[gbuf_addr]** |
