Skip to content

Latest commit

 

History

History
86 lines (56 loc) · 5.13 KB

www2exec-.dtors-and-.fini_array.md

File metadata and controls

86 lines (56 loc) · 5.13 KB
Raw

WWW2Exec - .dtors & .fini_array

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

.dtors

{% hint style="danger" %} Nowadays is very weird to find a binary with a .dtors section! {% endhint %}

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:

objdump -s -j .dtors /exec
rabin -s /exec | grep “__DTOR”

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.

{% hint style="warning" %} Ofc, you first need to find a place to store the shellcode in order to later call it. {% endhint %}

.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.

objdump -s -j .fini_array ./greeting

./greeting:     file format elf32-i386

Contents of section .fini_array:
 8049934 a0850408

#Put your address in 0x8049934

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 is 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.

{% hint style="danger" %} Note that with Full RELRO, the section .fini_array is made read-only. In newer versions, even with [Partial RELRO] the section .fini_array is made read-only also. {% endhint %}

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}