Exploits entmystifiziert, Teil 3

Per Heap-Spray-Technik zum Speicher-Exploit

| Autor / Redakteur: Thorsten Henning* / Stephan Augsten

Heap Exploits sind ein Glücksspiel, die Heap-Spraying-Technik erhöht die Erfolgschancen deutlich.
Heap Exploits sind ein Glücksspiel, die Heap-Spraying-Technik erhöht die Erfolgschancen deutlich. (Bild: Archiv)

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.

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.

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44025133 / Sicherheitslücken)