# Unsorted Bin Attack

{{#include ../../banners/hacktricks-training.md}}

## Grundinformationen

Für weitere Informationen darüber, was ein unsortierter Bin ist, siehe diese Seite:

{{#ref}}
bins-and-memory-allocations.md
{{#endref}}

Unsortierte Listen können die Adresse zu `unsorted_chunks (av)` in der `bk`-Adresse des Chunks schreiben. Daher, wenn ein Angreifer die **Adresse des `bk`-Zeigers** in einem Chunk innerhalb des unsortierten Bins **modifizieren** kann, könnte er in der Lage sein, **diese Adresse an einer beliebigen Adresse zu schreiben**, was hilfreich sein könnte, um Glibc-Adressen zu leaken oder einige Abwehrmaßnahmen zu umgehen.

Im Grunde genommen ermöglicht dieser Angriff, **eine große Zahl an einer beliebigen Adresse zu setzen**. Diese große Zahl ist eine Adresse, die eine Heap-Adresse oder eine Glibc-Adresse sein könnte. Ein typisches Ziel ist **`global_max_fast`**, um die Erstellung von Fast-Bin-Bins mit größeren Größen zu ermöglichen (und von einem unsortierten Bin-Angriff zu einem Fast-Bin-Angriff überzugehen).

> [!TIP]
> Ein Blick auf das Beispiel in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) zeigt, dass die Verwendung von 0x4000 und 0x5000 anstelle von 0x400 und 0x500 als Chunk-Größen (um Tcache zu vermeiden) dazu führt, dass der Fehler **`malloc(): unsorted double linked list corrupted`** ausgelöst wird.
>
> Daher erfordert dieser unsortierte Bin-Angriff jetzt (neben anderen Überprüfungen) auch, dass die doppelt verkettete Liste repariert wird, sodass `victim->bk->fd == victim` oder nicht `victim->fd == av (arena)` umgangen wird, was bedeutet, dass die Adresse, an die wir schreiben wollen, die Adresse des gefälschten Chunks in ihrer `fd`-Position haben muss und dass der gefälschte Chunk `fd` auf die Arena zeigt.

> [!CAUTION]
> Beachten Sie, dass dieser Angriff den unsortierten Bin (und damit auch kleine und große) beschädigt. Daher können wir jetzt nur **Allokationen aus dem Fast Bin verwenden** (ein komplexeres Programm könnte andere Allokationen durchführen und abstürzen), und um dies auszulösen, müssen wir **die gleiche Größe allokieren, sonst wird das Programm abstürzen.**
>
> Beachten Sie, dass das Überschreiben von **`global_max_fast`** in diesem Fall hilfreich sein könnte, da man darauf vertraut, dass der Fast Bin in der Lage ist, sich um alle anderen Allokationen zu kümmern, bis der Exploit abgeschlossen ist.

Der Code von [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) erklärt dies sehr gut, obwohl, wenn Sie die Mallocs ändern, um genügend Speicher zu allokieren, sodass sie nicht in einem Tcache enden, Sie sehen können, dass der zuvor erwähnte Fehler auftritt, der diese Technik verhindert: **`malloc(): unsorted double linked list corrupted`**

## Unsorted Bin Infoleak Attack

Dies ist tatsächlich ein sehr grundlegendes Konzept. Die Chunks im unsortierten Bin werden Zeiger haben. Der erste Chunk im unsortierten Bin wird tatsächlich die **`fd`**- und **`bk`**-Links **auf einen Teil der Hauptarena (Glibc)** zeigen.\
Daher, wenn Sie **einen Chunk in einen unsortierten Bin legen und ihn lesen** (use after free) oder **ihn erneut allokieren, ohne mindestens 1 der Zeiger zu überschreiben**, um ihn dann **zu lesen**, können Sie einen **Glibc-Infoleak** erhalten.

Ein ähnlicher [**Angriff, der in diesem Bericht verwendet wurde**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html), bestand darin, eine Struktur mit 4 Chunks (A, B, C und D - D dient nur dazu, die Konsolidierung mit dem Top-Chunk zu verhindern) zu missbrauchen, sodass ein Null-Byte-Overflow in B verwendet wurde, um C anzuzeigen, dass B ungenutzt war. Außerdem wurde in B die `prev_size`-Daten so modifiziert, dass die Größe anstelle der Größe von B A+B war.\
Dann wurde C deallokiert und mit A+B konsolidiert (aber B war weiterhin in Gebrauch). Ein neuer Chunk der Größe A wurde allokiert und dann wurden die geleakten Adressen der libc in B geschrieben, von wo sie geleakt wurden.

## Referenzen & Weitere Beispiele

- [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap)
- Das Ziel ist es, eine globale Variable mit einem Wert größer als 4869 zu überschreiben, sodass es möglich ist, die Flagge zu erhalten und PIE nicht aktiviert ist.
- Es ist möglich, Chunks beliebiger Größen zu generieren, und es gibt einen Heap-Overflow mit der gewünschten Größe.
- Der Angriff beginnt mit der Erstellung von 3 Chunks: chunk0, um den Overflow auszunutzen, chunk1, um überlaufen zu werden, und chunk2, damit der Top-Chunk die vorherigen nicht konsolidiert.
- Dann wird chunk1 freigegeben und chunk0 wird überlaufen, sodass der `bk`-Zeiger von chunk1 auf: `bk = magic - 0x10` zeigt.
- Dann wird chunk3 mit der gleichen Größe wie chunk1 allokiert, was den unsortierten Bin-Angriff auslöst und den Wert der globalen Variable ändert, wodurch es möglich wird, die Flagge zu erhalten.
- [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html)
- Die Merge-Funktion ist anfällig, da sie, wenn beide übergebenen Indizes gleich sind, darauf realloc und dann freigibt, aber einen Zeiger auf diesen freigegebenen Bereich zurückgibt, der verwendet werden kann.
- Daher werden **2 Chunks erstellt**: **chunk0**, das mit sich selbst zusammengeführt wird, und chunk1, um die Konsolidierung mit dem Top-Chunk zu verhindern. Dann wird die **Merge-Funktion mit chunk0** zweimal aufgerufen, was zu einem Use-After-Free führt.
- Dann wird die **`view`**-Funktion mit Index 2 (der Index des Use-After-Free-Chunks) aufgerufen, was **eine libc-Adresse leakt**.
- Da die Binärdatei Schutzmaßnahmen hat, um nur Malloc-Größen größer als **`global_max_fast`** zuzulassen, wird ein unsortierter Bin-Angriff verwendet, um die globale Variable `global_max_fast` zu überschreiben.
- Dann ist es möglich, die Edit-Funktion mit Index 2 (dem Use-After-Free-Zeiger) aufzurufen und den `bk`-Zeiger so zu überschreiben, dass er auf `p64(global_max_fast-0x10)` zeigt. Dann wird ein neuer Chunk erstellt, der die zuvor kompromittierte freigegebene Adresse (0x20) verwendet, was den **unsortierten Bin-Angriff** auslöst, der `global_max_fast` mit einem sehr großen Wert überschreibt, wodurch jetzt Chunks in Fast Bins erstellt werden können.
- Jetzt wird ein **Fast Bin Angriff** durchgeführt:
- Zunächst wird entdeckt, dass es möglich ist, mit Fast **Chunks der Größe 200** im **`__free_hook`**-Bereich zu arbeiten:
- <pre class="language-c"><code class="lang-c">gef➤  p &__free_hook
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
gef➤  x/60gx 0x7ff1e9e607a8 - 0x59
<strong>0x7ff1e9e6074f: 0x0000000000000000      0x0000000000000200
</strong>0x7ff1e9e6075f: 0x0000000000000000      0x0000000000000000
0x7ff1e9e6076f <list_all_lock+15>:      0x0000000000000000      0x0000000000000000
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000      0x0000000000000000
</code></pre>
- Wenn es uns gelingt, einen Fast Chunk der Größe 0x200 an diesem Ort zu erhalten, wird es möglich sein, einen Funktionszeiger zu überschreiben, der ausgeführt wird.
- Dazu wird ein neuer Chunk der Größe `0xfc` erstellt und die Merge-Funktion wird mit diesem Zeiger zweimal aufgerufen, sodass wir einen Zeiger auf einen freigegebenen Chunk der Größe `0xfc*2 = 0x1f8` im Fast Bin erhalten.
- Dann wird die Edit-Funktion in diesem Chunk aufgerufen, um die **`fd`**-Adresse dieses Fast Bins so zu ändern, dass sie auf die vorherige **`__free_hook`**-Funktion zeigt.
- Dann wird ein Chunk der Größe `0x1f8` erstellt, um den vorherigen nutzlosen Chunk aus dem Fast Bin abzurufen, sodass ein weiterer Chunk der Größe `0x1f8` erstellt wird, um einen Fast Bin Chunk im **`__free_hook`** zu erhalten, der mit der Adresse der **`system`**-Funktion überschrieben wird.
- Und schließlich wird ein Chunk, der die Zeichenfolge `/bin/sh\x00` enthält, freigegeben, indem die Delete-Funktion aufgerufen wird, was die **`__free_hook`**-Funktion auslöst, die auf system mit `/bin/sh\x00` als Parameter zeigt.
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
- Ein weiteres Beispiel für den Missbrauch eines 1B-Overflows zur Konsolidierung von Chunks im unsortierten Bin und zum Erhalten eines libc-Infoleaks und dann zur Durchführung eines Fast Bin-Angriffs, um den Malloc-Hook mit einer One-Gadget-Adresse zu überschreiben.
- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
- Wir können nur Chunks mit einer Größe größer als `0x100` allokieren.
- Überschreiben von `global_max_fast` mit einem Unsorted Bin-Angriff (funktioniert 1/16 Mal aufgrund von ASLR, da wir 12 Bits modifizieren müssen, aber 16 Bits modifizieren müssen).
- Fast Bin-Angriff, um ein globales Array von Chunks zu modifizieren. Dies gibt eine beliebige Lese-/Schreibprimitive, die es ermöglicht, die GOT zu modifizieren und einige Funktionen auf `system` zu zeigen.

{{#include ../../banners/hacktricks-training.md}}