Exploits entmystifiziert, Teil 3 Per Heap-Spray-Technik zum Speicher-Exploit

Grundlagen zur Ausnutzung von Speicherfehlern und den Stack-basierten Pufferüberlauf hat diese Exploit-Beitragsreihe schon beleuchtet. Wie der Heap-Exploit von Angreifern begünstigt wird, wollen wir nun im Folgenden genauer betrachten.

Anbieter zum Thema

TXOne Networks

Arctic Wolf Networks Germany GmbH

Palo Alto Networks

Der Exploitation-Prozess setzt sich gemäß des ersten Teils dieser Serie aus folgenden Teilen zusammen: Überschreiben einer Adresse im Prozess-Speicherraum > Umleiten der Ausführungsabfolge zur Shellcode-Adresse > Ausführen des Shellcodes. Im zweiten Teil ging es um die Umsetzung des Überschreibens und Umleitens durch Stack- d.h. Stapel-basierte Pufferüberlauf-Schwachstellen.

Nun widmen wir uns Heap-basierten Exploits. Hierzu muss man erst einmal klären, was ein Heap ist: in Betriebssystem (OS) weist einem Computerprogramm Speicher zu, abgestimmt auf die Größe der Daten, die dieses Programm verbraucht. Die Datengröße ist entweder bekannt oder wird während der Runtime bestimmt, also während das Programm läuft.

In dieser Beitragsreihe wurde bereits der Stack als OS-Allokationsmechanismus beschrieben. Der Heap hingegen ist der Speicherpool, aus dem heraus dynamische Datenanforderungen erfüllt werden. Aus der Perspektive der Suche nach einer Schwachstelle oder Exploit-Möglichkeit ergeben sich zwei wesentliche Unterschiede zwischen Stack und Heap:

1. Heap-Speicher muss explizit angefordert werden.

Das Programm fragt nach einem Chunk, also einem Speicherstück in einer bestimmten Größe, und erhält einen Pointer (Zeiger), der auf die erste Adresse dieses Speicherstücks zeigt. Ein Pointer stellt somit eine Verknüpfung zu den gespeicherten Daten her. Je nach Speicherkonzept reicht es, nur die Pointer zu speichern, da diese die Verbindung zu den Datensätzen enthalten. Man erspart sich dadurch die Speicherung von Metadaten. Das Programm sollte das Speicherstück, auf das der Pointer zeigt, wieder freigeben, wenn es seine Aufgabe abgeschlossen hat. Diese Request-free-Logik ist die Ursache für die gängigen Schwachstellen der Kategorie „Use-after-free/double-free“.

2. Der Heap ist deutlich größer als der Stack

Dies macht eine genaue Vorhersage der Adresse des Shellcodes viel komplizierter als im Stack. Genau dies wiederum ist der Treiber der „Heap Spray“-Exploit-Technik, die in den meisten aller Heap-basierten Exploits gängige Praxis ist.

Speicherkorruptions-Exploits nutzen einen Shellcode, der in einer manuell erstellten Dateneingabedatei platziert wird, um eine Schwachstelle bei der Verarbeitung der Anwendung auszulösen. Diese Sicherheitslücke macht einen Einstieg in den Prozessspeicherbereich möglich. Dies nutzt der Angreifer aus, um den Ausführungsfluss in Richtung der Shellcode-Adresse umzuleiten. Hierzu muss noch erklärt werden, wie die Prozessteile Overwrite (Überschreiben) und Redirect (Umleiten) auf dem Heap implementiert sind.

(ID:44025133)