Checksec
Canary : ✓
NX : ✓
PIE : ✘
Fortify : ✘
RelRO : ✘
RelRO is completely disabled unlike any other challenge we have encountered, this means that we have write permessions to all the relocations.
Exploitation
Running the binary will let us specify an address and a value and then It will assign that value to the adderss we provided.
hegz@pop-os$ ./detour
What: 1234
Where: 123123123213
Segmentation fault (core dumped)
I confirmed this by analyzing the binary in ghidra, below is the decompilation.
|
|
This is the part responsible of the write-what-where.
|
|
It basically means that It will write the value we provide in local_20
at the address we provide at local_18
incremented by the address of base
, this is important when crafting our exploit as we have to subtract the address of base from the address we provide to get the correct address in the binary.
We also have a function that will execute a shell in our binary.
|
|
Now we only need to locate the address that we will be writing to in order to redirect execution to our win() function.
The GOT is one good attack vector but we don’t call any libc function (except __stack_chk_fail) after our write-what-where, this means that overwriting the GOT is useless since the overwritten GOT entry will never be referenced anyway.
The less obvious attack vector is the global destructor for our program, this is possible due the fact that we have write permissions to the binary relocations.
The global destructor is a routine that gets called when our main function is exiting.
Here is the backtrace of the binary after successfully ovewrwriting the global destructor.
|
|
It is present in the .fini_array section under the symbol name __do_global_dtors_aux_fini_array_entry
Time to craft our exploit.
|
|