Skip to content

Latest commit

 

History

History
73 lines (53 loc) · 7.87 KB

tcache-bin-attack.md

File metadata and controls

73 lines (53 loc) · 7.87 KB
Raw

Tcache Bin Attack

{% 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 %}

Basic Information

For more information about what is a Tcache bin check this page:

{% content-ref url="bins-and-memory-allocations.md" %} bins-and-memory-allocations.md {% endcontent-ref %}

First of all, note that the Tcache was introduced in Glibc version 2.26.

The Tcache attack (also known as Tcache poisoning) proposed in the guyinatuxido page is very similar to the fast bin attack where the goal is to overwrite the pointer to the next chunk in the bin inside a freed chunk to an arbitrary address so later it's possible to allocate that specific address and potentially overwrite pointes.

However, nowadays, if you run the mentioned code you will get the error: malloc(): unaligned tcache chunk detected. So, it's needed to write as address in the new pointer an aligned address (or execute enough times the binary so the written address is actually aligned).

Tcache indexes attack

Usually it's possible to find at the beginning of the heap a chunk containing the amount of chunks per index inside the tcache and the address to the head chunk of each tcache index. If for some reason it's possible to modify this information, it would be possible to make the head chunk of some index point to a desired address (like __malloc_hook) to then allocated a chunk of the size of the index and overwrite the contents of __malloc_hook in this case.

Examples

  • CTF https://guyinatuxedo.github.io/29-tcache/dcquals19_babyheap/index.html
    • Libc info leak: It's possible to fill the tcaches, add a chunk into the unsorted list, empty the tcache and re-allocate the chunk from the unsorted bin only overwriting the first 8B, leaving the second address to libc from the chunk intact so we can read it.
    • Tcache attack: The binary is vulnerable a 1B heap overflow. This will be abuse to change the size header of an allocated chunk making it bigger. Then, this chunk will be freed, adding it to the tcache of chunks of the fake size. Then, we will allocate a chunk with the faked size, and the previous chunk will be returned knowing that this chunk was actually smaller and this grants up the opportunity to overwrite the next chunk in memory.
      We will abuse this to overwrite the next chunk's FD pointer to point to malloc_hook, so then its possible to alloc 2 pointers: first the legit pointer we just modified, and then the second allocation will return a chunk in malloc_hook that it's possible to abuse to write a one gadget.
  • CTF https://guyinatuxedo.github.io/29-tcache/plaid19_cpp/index.html
    • Libc info leak: There is a use after free and a double free. In this writeup the author leaked an address of libc by readnig the address of a chunk placed in a small bin (like leaking it from the unsorted bin but from the small one)
    • Tcache attack: A Tcache is performed via a double free. The same chunk is freed twice, so inside the Tcache the chunk will point to itself. Then, it's allocated, its FD pointer is modified to point to the free hook and then it's allocated again so the next chunk in the list is going to be in the free hook. Then, this is also allocated and it's possible to write a the address of system here so when a malloc containing "/bin/sh" is freed we get a shell.
  • CTF https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps0/index.html
    • The main vuln here is the capacity to free any address in the heap by indicating its offset
    • Tcache indexes attack: It's possible to allocate and free a chunk of a size that when stored inside the tcache chunk (the chunk with the info of the tcache bins) will generate an address with the value 0x100. This is because the tcache stores the amount of chunks on each bin in different bytes, therefore one chunk in one specific index generates the value 0x100.
    • Then, this value looks like there is a chunk of size 0x100. Allowing to abuse it by free this address. This will add that address to the index of chunks of size 0x100 in the tcache.
    • Then, allocating a chunk of size 0x100, the previous address will be returned as a chunk, allowing to overwrite other tcache indexes.
      For example putting the address of malloc hook in one of them and allocating a chunk of the size of that index will grant a chunk in calloc hook, which allows for writing a one gadget to get a s shell.
  • CTF https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps1/index.html
    • Same vulnerability as before with one extra restriction
    • Tcache indexes attack: Similar attack to the previous one but using less steps by freeing the chunk that contains the tcache info so it's address is added to the tcache index of its size so it's possible to allocate that size and get the tcache chunk info as a chunk, which allows to add free hook as the address of one index, alloc it, and write a one gadget on it.
  • Math Door. HTB Cyber Apocalypse CTF 2023
    • Write After Free to add a number to the fd pointer.
    • A lot of heap feng-shui is needed in this challenge. The writeup shows how controlling the head of the Tcache free-list is pretty handy.
    • Glibc leak through stdout (FSOP).
    • Tcache poisoning to get an arbitrary write primitive.

{% 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 %}