WWW2Exec - .dtors & .fini_array
.dtors
Nowadays is very weird to find a binary with a .dtors section!
The destructors are functions that are executed before program finishes (after the main
function returns).
The addresses to these functions are stored inside the .dtors
section of the binary and therefore, if you manage to write the address to a shellcode in __DTOR_END__
, that will be executed before the programs ends.
Get the address of this section with:
Usually you will find the DTOR markers between the values ffffffff
and 00000000
. So if you just see those values, it means that there isn't any function registered. So overwrite the 00000000
with the address to the shellcode to execute it.
Ofc, you first need to find a place to store the shellcode in order to later call it.
.fini_array
Essentially this is a structure with functions that will be called before the program finishes, like .dtors
. This is interesting if you can call your shellcode just jumping to an address, or in cases where you need to go back to main
again to exploit the vulnerability a second time.
Note that when a function from the .fini_array
is executed it moves to the next one, so it won't be executed several time (preventing eternal loops), but also it'll only give you 1 execution of the function placed here.
Note that entries in .fini_array
are called in reverse order, so you probably wants to start writing from the last one.
Eternal loop
In order to abuse .fini_array
to get an eternal loop you can check what was done here: If you have at least 2 entries in .fini_array
, you can:
Use your first write to call the vulnerable arbitrary write function again
Then, calculate the return address in the stack stored by
__libc_csu_fini
(the function that it calling all the.fini_array
functions) and put there the address of__libc_csu_fini
This will make
__libc_csu_fini
call himself again executing the.fini_array
functions again which will call the vulnerable WWW function 2 times: one for arbitrary write and another one to overwrite again the return address of__libc_csu_fini
on the stack to call itself again.
Note that with Full RELRO, the section .fini_array
is made read-only.
link_map
As explained in this post, If the program exist using return
or exit()
it'll run __run_exit_handlers()
which will call registered destructors.
If the program exits via _exit()
function, it'll call the exit
syscall and the exit handlers will not be executed. So, to confirm __run_exit_handlers()
is executed you can set a breakpoint on it.
The important code is (source):
Note how map -> l_addr + fini_array -> d_un.d_ptr
is used to calculate the position of the array of functions to call.
There are a couple of options:
Overwrite the value of
map->l_addr
to make it point to a fakefini_array
with instructions to execute arbitrary codeOverwrite
l_info[DT_FINI_ARRAY]
andl_info[DT_FINI_ARRAYSZ]
entries (which are more or less consecutive in memory) , to make them points to a forgedElf64_Dyn
structure that will make againarray
points to a memory zone the attacker controlled.This writeup overwrites
l_info[DT_FINI_ARRAY]
with the address of a controlled memory in.bss
containing a fakefini_array
. This fake array contains first a one gadget address which will be executed and then the difference between in the address of this fake array and the value ofmap->l_addr
so*array
will point to the fake array.According to main post of this technique and this writeup ld.so leave a pointer on the stack that points to the binary
link_map
in ld.so. With an arbitrary write it's possible to overwrite it and make it point to a fakefini_array
controlled by the attacker with the address to a one gadget for example.
Following the previous code you can find another interesting section with the code:
In this case it would be possible to overwrite the value of map->l_info[DT_FINI]
pointing to a forged ElfW(Dyn)
structure. Find more information here.
TLS-Storage dtor_list overwrite in __run_exit_handlers
__run_exit_handlers
As explained here, if a program exits via return
or exit()
, it'll execute __run_exit_handlers()
which will call any destructors function registered.
Code from _run_exit_handlers()
:
Code from __call_tls_dtors()
:
For each registered function in tls_dtor_list
, it'll demangle the pointer from cur->func
and call it with the argument cur->obj
.
Using the tls
function from this fork of GEF, it's possible to see that actually the dtor_list
is very close to the stack canary and PTR_MANGLE cookie. So, with an overflow on it's it would be possible to overwrite the cookie and the stack canary.
Overwriting the PTR_MANGLE cookie, it would be possible to bypass the PTR_DEMANLE
function as setting it to 0x00, will mean that the xor
used to get the real address is just the address configured. Then, writing on the dtor_list
it's possible chain several functions with the function address and it's argument.
Finally notice that the stored pointer is not only going to be xored with the cookie but also rotated 17 bits:
So you need to take this into account before adding a new address.
Find an example in the original post.
Other mangled pointers in __run_exit_handlers
__run_exit_handlers
This technique is explained here and depends again on the program exiting calling return
or exit()
so __run_exit_handlers()
is called.
Let's check more code of this function:
The variable f
points to the initial
structure and depending on the value of f->flavor
different functions will be called.
Depending on the value, the address of the function to call will be in a different place, but it'll always be demangled.
Moreover, in the options ef_on
and ef_cxa
it's also possible to control an argument.
It's possible to check the initial
structure in a debugging session with GEF running gef> p initial
.
To abuse this you need either to leak or erase the PTR_MANGLE
cookie and then overwrite a cxa
entry in initial with system('/bin/sh')
.
You can find an example of this in the original blog post about the technique.
Last updated