Schutzmaßnahmen: ASLR kann unterlaufen werden
Eine der ersten beiden Schutzmaßnahmen gegen Angriffe auf Pufferüberlauf-Schwachstellen ist die Data Execution Prevention (DEP). Da sie sich umgehen lässt, reicht sie als alleiniger Schutz nicht aus. Zusätzlichen Schutz bietet die Adress Space Layout Randomization (ASLR), aber auch diese Schutzmaßnahme lässt sich natürlich umgehen.
Angriffe trotz ASLR
Eine Reihe von Möglichkeiten zum Umgehen von ASLR wurden auf der Sicherheitskonferenz Black Hat USA 2008 von Alexander Sotirov und Mark Dowd beschrieben: "How To Impress Girls With Browser Memory Protection Bypasses".
Statisch geladene DLLs und Programme
ASLR ist nur wirksam, wenn wirklich alle Adressen im Adressraum des angegriffenen Prozesses zufällig gewählt wurden. Bleiben einige Objekte wie zum Beispiel DLLs an konstanten Adressen, kann der Angreifer einfach diese Daten für seinen Angriff nutzen. So ein Angriff ist besonders auf Webbrowser interessant, da dort durch das mögliche Laden vieler Plugins die Wahrscheinlichkeit sehr gross ist, Bibliotheken zu finden, die ASLR nicht verwenden. Der Angreifer muss dann nur dafür sorgen, dass das gewünschte Plugin geladen wird, bevor sein Exploit den Pufferüberlauf auslöst.
Praktisch statisch geladene Objekte
Eine Variation der tatsächlich statisch geladenen Objekte sind
Objekte, die zwar eigentlich keine feste Adresse haben, aber trotzdem immer
in bestimmten Speicherbereichen geladen werden. Besonders gefährlich
sind Objekte, die vom Benutzer auf eine beliebige Größe gebracht
werden können. Beim sogenannten "Heap Spraying" wird der regulär
verfügbare Speicher aufgebraucht, so dass der Heap wachsen muss. Da
die Speicherreservierungen relativ linear erfolgen und der virtuelle
Adressraum begrenzt ist, kann der Angreifer abschätzen, wohin Daten
geladen werden.
Zum Beispiel verschiebt die Heap-Randomization von Windows Vista die
Startadresse um bis zu 2MB. Kann ein Angreifer mehr als 2 MB Speicher auf
dem Heap reservieren, kann er unabhängig von der Heap-Randomization
einen gültigen Pointer zu den Daten raten.
Teilweises Überschreiben von Pointern
Beim teilweisen Überschreiben von Pointern werden nur die niedrigwertigsten 1 oder 2 Byte des Pointers manipuliert. Bei aktivierter ASLR kann so ein Angriff zum Erfolg führen, da der Angreifer nicht die vollständige Adresse seines Zielobjekts im Speicher kennen muss, sondern nur den relativen Ort, ausgehen von dem Ort, auf den der Pointer ursprünglich zeigte.
Informationslecks verraten Adressen
Zu guter Letzt besteht die Möglichkeit, dass der Angreifer über Informationslecks nützliche Informationen über den Speicheraufbau oder den Status des Zielprozesses erhält. Im Fall von ASLR sind besonders Pointer-Werte interessant, da darüber die Adresse eines Objekts im Speicher ermittelt werden kann und der Pointer unter Umständen weitere Informationen über das Objekt, auf das er verweist, preisgibt. Jede dieser Informationen kann dem Angreifer den Weg zu den von ihn gesuchten Daten weisen.
Heap Spraying
Alexander Sotirov und Mark Dowd konnten DEP und ASLR unter Windows Vista dank Java umgehen. Die Java Virtual Machine (JVM) verwendet eine eigene Speicherverwaltung, die vom System allen Speicher mit gesetzten PAGE_EXECUTE_READWRITE-Bits, also ausführbar, anfordert. Dadurch werden Probleme mit der DEP verhindert, die DEP aber auch ausgehebelt. Ein Java-Applet füllt den Heap über Heap Spraying mit Shellcode, der dann über eine überschriebene Rücksprungadresse angesprungen wird.
Die Startadresse des Heap konnten Alexander Sotirov und Mark Dowd ermitteln, da die JVM ein Archiv mit den System-Klassen immer an die gleiche Adresse lädt und der Heap sich an diese Klassen anschließt.
Flash Player DLLs missbraucht
Eine weitere Möglichkeit, DEP und ASLR unter Windows Vista zu umgehen,
ist der Missbrauch von ASLR-inkompatiblen DLLs, die an festen Adressen
geladen werden. Konkret wurde die Bibliothek Flash9f.ocx
aus
dem Flash Player Version 9.0.124.0 missbraucht, die immer an die
Basis-Adresse 0x30000000 geladen wird. Durch einen Pufferüberlauf
wurde der Stack so manipuliert, dass Code in der Flash9f.ocx
angesprungen wurde. Darüber wurde der DEP-Schutz für den auf den
Heap eingeschleusten Shellcode aufgehoben, so dass danach der Shellcode
ausgeführt werden konnte.
In der nächsten Folge geht es um weitere Möglichkeiten, ASLR zu umgehen.
Übersicht über alle Artikel zum Thema
- Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 1
- Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 2
- Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 3
- Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 4
- Schutzmaßnahmen: Der Pufferüberlauf im Überblick
- Schutzmaßnahmen: Canary und DEP gegen Pufferüberlauf-Schwachstellen
- Schutzmaßnahmen: ASLR gegen Pufferüberlauf-Schwachstellen
- Schutzmaßnahmen: ASLR kann unterlaufen werden
- Schutzmaßnahmen: Weitere Angriffe trotz ASLR
Trackbacks
Dipl.-Inform. Carsten Eilers am : 0-Day-Schwachstelle im Internet Explorer, die dritte
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 1.2014 - Wie sicher ist Windows 8?
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Wasserloch-Angriffe über 0-Day-Schwachstelle im Internet Explorer
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : 0-Day-Schwachstelle im Flash Player, die zweite (im Februar 2014)
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 10.2014 - Das Enhanced Mitigation Experience Toolkit als Schutz vor 0-Day-Exploits
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Microsoft patcht, und wieder sind 0-Day-Schwachstellen dabei!
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: Mobile Technology 4.2015 - Android auf der Black Hat USA 2015
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 7.16 - Alles im Fluss?
Vorschau anzeigen