Make unsorted bin attack great again!

[MaherAzzouzi]

Corrupting the bk of a freed unsorted bin attack can be exploited to gain shell or any other security impact.
The technique was found when auditing GlibC 2.32 source code, but it's working against GlibC 2.34 too.

[Kyle-Kyle]

If I understand correctly, this technique requires known heap addresses (fake chunk and p) and a target address (where to overwrite). In the demo attack, it uses out-of-bound access to achieve chunk overlapping. In addition, this attack can work in UAF and potentially also double-free scenarios. It does not only do chunk overlapping, it can also lead to arbitrary allocation.

Unfortunately, this attack is not the unsorted bin attack that got killed in glibc-2.29. unsorted bin attack only requires a target address. It can overwrite the value at the target address without knowing the heap address. That's what makes it powerful.

In fact, what this attack wants to achieve is to chain a fake chunk into the unsorted bin list, which is extremely hard without knowing heap addresses after the patch. But with a heap leak, it is easy to achieve once you know the goal is to chain a chunk into unsorted bin list.

I'd suggest you see whether you can achieve the same goal without heap leak. You may achieve it through partial overwrite and reuse the heap values left on heap like how we exploit poisonous_null_byte.

[MaherAzzouzi]

Yep that's correct, but for me I didn't found a house on the internet that target the same issue so I tried to did it my self, after founding it. Yeah it's inserting it to the list and taking it but it's mitigated too that's why libc leak is required. I don't know if you already know about this attack but I didn't found it when I was studying heap exploitation. Thanks.

…

On Tue, Oct 19, 2021, 02:49 Kyle Zeng ***@***.***> wrote: If I understand correctly, this technique requires a known heap address (fake chunk) and a target address (where to overwrite). In the demo attack, it uses out-of-bound access to achieve chunk overlapping. In addition, this attack can work in UAF and potentially also double-free scenarios. It does not only do chunk overlapping, it can also lead to arbitrary allocation. Unfortunately, this attack is not the unsorted bin attack that got killed in glibc-2.29. unsorted bin attack only requires a target address <https://github.com/shellphish/how2heap/blob/master/glibc_2.27/unsorted_bin_attack.c>. It can overwrite the value at the target address without knowing the heap address. That's what makes it powerful. In fact, what this attack wants to achieve is to chain a fake chunk into the unsorted bin list, which is extremely hard without knowing heap addresses after the patch <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b90ddd08f6dd688e651df9ee89ca3a69ff88cd0c>. But with a heap leak, it is easy to achieve once you know the goal is to chain a chunk into unsorted bin list. I'd suggest you see whether you can achieve the same goal without heap leak. You may achieve it through partial overwrite and exploit the heap values left on heap like how we exploit poisonous_null_byte <https://github.com/shellphish/how2heap/blob/64bb684d3cda469fc4f9ead69f2477be9596b570/glibc_2.34/poison_null_byte.c> . — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO2Y5LTYTJ64FRLIUDN3HR3UHTFCLANCNFSM5GHN5RQQ> .

[Kyle-Kyle]

Good job on finding this technique independently!

However, this technique is not new; it has been extensively used in current techniques. For example, the same attack is used in house_of_einherjar, a similar idea is used in poison_null_byte (not in unsorted bin but in large bin).

Although it is not new, I think this technique should be merged into the repo because it is always good to have atomic techniques that are easy to learn and necessary for mastering compound techniques later.

Before it gets merged, a few changes need to be made though:

1. change of the name. It shouldn't be called unsorted_bin_attack which is another technique that does not require heap leak. It should be called unsorted bin injection or sort.
2. line 60 is libc build dependent, which is not good. You can change it to ul heap_base = p & ~(0xfffL)
3. I don't think line 82 needs the + 0x8

[Kyle-Kyle]

Also, please add more output to the program to allow people understand how it works by only reading its output.
And please explicitly mention what primitives this technique requires (heap leak + another primitive) and how this technique is different from the original unsorted_bin_attack.

Thanks!

[Kyle-Kyle]

@MaherAzzouzi you mentioned that libc leak is required. That is not true. You can have three unsorted bin chunks head->A->B->C->head. Now all both fwd and bk pointers in B are heap pointers. You can use overflow to overwrite B's fwd and bk pointers to preserve its fwd pointer and change the bk pointer to a fake chunk X. And then you overwrite C's fwd pointer to X. Now you let X's fwd pointer to be B and X's bk pointer to be C. Now you have head->A->B->X->C->head. You successfully inserted X between B and C without knowing libc address (head)!

[MaherAzzouzi]

Yeah you're totally right I can insert one in the middle and only use heap leak, but sometimes a one freed chunk is all you have (the case of the challenge I was doing), and many more.
For suggestions 1 and 2 you're right the name can make an ambiguity with the old attack and I will change it, for the third suggestion it need to be + 0x8, else you will have the following error : malloc(): unsorted double linked list corrupted
I will try to add more output to the PoC when I have time.
Thanks for your time, and thanks for reviewing this technique.