Skip to content

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.

Carsten Eilers


Ü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
Es gibt schon wieder eine 0-Day-Schwachstelle im Internet Explorer. Insgesamt die 15. in diesem Jahr, und die dritte im Internet Explorer (und dann gab es da ja auch noch die Ende Dezember 2012 im IE gemeldete, die es fast in dieses Jahr geschaff

Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 1.2014 - Wie sicher ist Windows 8?

Vorschau anzeigen
Im windows.developer 1.2014 ist ein Artikel über die Entwicklung der Sicherheit von Windows 8 seit seinem Erscheinen erschienen. Seit der Veröffentlichung von Windows 8 ist etwas mehr als ein Jahr vergangen. Ein Jahr, in dem es kei

Dipl.-Inform. Carsten Eilers am : Wasserloch-Angriffe über 0-Day-Schwachstelle im Internet Explorer

Vorschau anzeigen
Die zweite 0-Day-Schwachstelle des Jahres 2014 befindet sich im Internet Explorer und wird im Rahmen von Wasserloch-Angriffen über die Website der "U.S. Veterans of Foreign Wars" ausgenutzt. FireEye hat den Exploit am 11. Februar entdeckt

Dipl.-Inform. Carsten Eilers am : 0-Day-Schwachstelle im Flash Player, die zweite (im Februar 2014)

Vorschau anzeigen
Die dritte 0-Day-Schwachstelle des Jahres befindet sich im Flash Player. Und weil das so harmlos klingt: Es ist nicht nur die dritte 0-Day-Schachstelle des Jahres, sondern auch des Monats - die erste wurde von Adobe am 4. Februar behoben, am 13.

Dipl.-Inform. Carsten Eilers am : Microsoft patcht, und wieder sind 0-Day-Schwachstellen dabei!

Vorschau anzeigen
Auch am Februar-Patchday hat Microsoft wieder einige 0-Day-Schwachstellen behoben. Für eine davon gibt es sogar einen 0-Day-Exploit. Zum Glück werden davon aber nur Schutzmaßnahmen umgangen und kein Code ausgeführt. Obwohl auc

Dipl.-Inform. Carsten Eilers am : Drucksache: Mobile Technology 4.2015 - Android auf der Black Hat USA 2015

Vorschau anzeigen
Im Magazin Mobile Technology 4.2015 ist ein Artikel über die auf der Black Hat USA 2015 vorgestellten Schwachstellen in und Angriffe auf Android wie Stagefright und Certifi-gate erschienen. Die Sicherheitsforscher haben auf der Black

Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 7.16 - Alles im Fluss?

Vorschau anzeigen
Im windows.developer 7.16 ist ein Artikel über Angriffe auf den Kontrollfluss von .NET-Anwendungen erschienen. Das alte Wettrennen zwischen Angreifern auf und Verteidigern von Windows-Rechnern geht in eine neue Runde: Auf der DEF CON 2