Large 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

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Basic Information

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

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

It's possible to find a great example in how2heap - large bin attack.

Basically here you can see how, in the latest "current" version of glibc (2.35), it's not checked: P->bk_nextsize allowing to modify an arbitrary address with the value of a large bin chunk if certain conditions are met.

In that example you can find the following conditions:

A large chunk is allocated
A large chunk smaller than the first one but in the same index is allocated
- Must be smalled so in the bin it must go first
(A chunk to prevent merging with the top chunk is created)
Then, the first large chunk is freed and a new chunk bigger than it is allocated -> Chunk1 goes to the large bin
Then, the second large chunk is freed
Now, the vulnerability: The attacker can modify chunk1->bk_nextsize to [target-0x20]
Then, a larger chunk than chunk 2 is allocated, so chunk2 is inserted in the large bin overwriting the address chunk1->bk_nextsize->fd_nextsize with the address of chunk2

{% hint style="success" %} There are other potential scenarios, the thing is to add to the large bin a chunk that is smaller than a current X chunk in the bin, so it need to be inserted just before it in the bin, and we need to be able to modify X's bk_nextsize as thats where the address of the smaller chunk will be written to. {% endhint %}

This is the relevant code from malloc. Comments have been added to understand better how the address was overwritten:

{% code overflow="wrap" %}

/* if smaller than smallest, bypass loop below */
assert (chunk_main_arena (bck->bk));
if ((unsigned long) (size) < (unsigned long) chunksize_nomask (bck->bk))
  {
    fwd = bck; // fwd = p1
    bck = bck->bk; // bck = p1->bk 

    victim->fd_nextsize = fwd->fd; // p2->fd_nextsize = p1->fd (Note that p1->fd is p1 as it's the only chunk)
    victim->bk_nextsize = fwd->fd->bk_nextsize; // p2->bk_nextsize = p1->fd->bk_nextsize
    fwd->fd->bk_nextsize = victim->bk_nextsize->fd_nextsize = victim; // p1->fd->bk_nextsize->fd_nextsize = p2
  }

{% endcode %}

This could be used to overwrite the global_max_fast global variable of libc to then exploit a fast bin attack with larger chunks.

You can find another great explanation of this attack in guyinatuxedo.

Other examples

La casa de papel. HackOn CTF 2024
- Large bin attack in the same situation as it appears in how2heap.
- The write primitive is more complex, because global_max_fast is useless here.
- FSOP is needed to finish the exploit.