Schutzmaßnahmen: ASLR gegen Pufferüberlauf-Schwachstellen
Eine der ersten beiden Schutzmaßnahmen gegen Angriffe auf Pufferüberlauf-Schwachstellen ist die Data Execution Prevention (DEP). Aber die lässt sich umgehen, reicht also als alleiniger Schutz nicht aus.
Angriff trotz DEP
Beim klassischen Angriff auf eine Pufferüberlauf-Schwachstelle schreibt der Angreifer seinen Schadcode auf den Stack oder den Heap und springt ihn dann durch eine Manipulation der Rücksprungadresse auf dem Stack an. Wird über die DEP verhindert, dass Code auf dem Stack oder im Heap ausgeführt wird, schlägt diese Taktik fehl. Die Pufferüberlauf-Schwachstelle existiert aber trotz DEP, der Angreifer muss also nur nach einem Weg suchen, die DEP zu umgehen. Ein solcher Weg ist der Return-to-libc-Angriff.
Rücksprung in die C-Library
Beim "Return (in)to libc" springt der Angreifer keinen eigenen,
eingeschleusten Code an, sondern Funktionen der C-Library libc. Die stellt
eine Vielzahl von Funktionen für C-Programm bereit und ist
naturgemäß ausführbar. Der Angreifer muss also "nur" die
Rücksprungadresse auf dem Stack mit der Adresse einer libc-Funktion
seiner Wahl überschreiben, um diese Funktion anstelle der eigentlich
im Programmablauf vorgesehenen auszuführen. Gut geeignet ist
dafür zum Beispiel die Funktion system()
zum
Ausführen beliebiger Systemprogramme, dem dann nur noch das
auszuführende Programm übergeben werden muss. Die DEP ist bei so
einem Angriff wirkungslos, da nur für die Ausführung von Code
vorgesehene Speicherbereiche angesprungen werden. Ein Canary zum Erkennen
des Pufferüberlaufs ist wirksam, da beim Angriff der
canary
-Wert überschrieben wird. Es gibt jedoch auch
Möglichkeiten, diesen Schutz zu umgehen
(PDF).
Aber das würde hier jetzt zu weit führen. Kommen wir zurück
zum Return-to-libc-Angriff und DEP.
Auf 32-Bit-Systemen sind Return-to-libc-Angriff relativ leicht zu realisieren, da die Parameter für die libc-Funktionen ebenfalls über den Stack übergeben werden. Und der kann ja durch den Pufferüberlauf nahezu nach Belieben manipuliert werden. Auf 64-Bit-Systemen dagegen werden die Parameter über Prozessorregister übergeben, und die lassen sich vom Angreifer nicht manipulieren. Aber schon 2005 zeigte Sebastian Krahmer von Suse, wie ein Angreifer durch das Kombinieren von Codefragmenten aus Standardbibliotheken beliebige Register mit den über den Pufferüberlauf eingeschleusten Werten besetzen kann. Dadurch sind Return-to-libc-Angriffe auch unter 64-Bit-Systemen möglich (PDF). Sebastian Krahmer nannte diesen Angriff "Code Chunk Borrow Technique", da kleine Teile des Codes neu kombiniert werden.
Außer dem Return-to-libc-Angriff gibt es weitere entsprechende Angriffe, die alle zusammen unter dem Begriff Return-oriented programming (ROP) zusammengefasst werden. Alle laufen darauf hinaus, dass der Angreifer die Kontrolle über den Programmablauf übernimmt und vorhandenen Code anspringt.
Da die DEP umgangen werden kann, muss eine neue, zusätzliche Schutzmaßnahme her. Was könnte man gegen die Return-to-libc-Angriffe machen?
Die Lösung: Das Finden von Code erschweren
Return-to-libc-Angriffe funktionieren nur, wenn der Angreifer weiß, wohin er springen muss. Da der Speicher der Reihe nach an die Programme vergeben wird und jedes Programm einen einheitlichen Speicherbereich belegt, ist das relativ einfach. Aber was wäre, wenn der Speicher nicht mehr so gleichmäßig vergeben würde, sondern jedem Programm eine zufällige Auswahl an Speicherblöcken zugewiesen würde? Oder jedes Programm seine Bibliotheken zufällig im zugewiesenen Speicher verteilen würde? Dann wüssten die Angreifer nicht mehr, an welchen Adressen die gesuchten Funktionen oder Code-Fragmente zu finden sind, und das Anspringen wird zum Glücksspiel.
Und genau so wurde das Problem auch gelöst. Das Verfahren wird als Adress Space Layout Randomization (ASLR) bezeichnet. Mit ASLR werden die Adressbereiche den Programmen auf zufälliger Basis zugewiesen. Codesegment, Heap und Stack beginnen an zufällig gewählten Adressen, und auch die Bibliotheken werden bei jedem Programmstart an andere zufällige Adressen geladen. Ein Angreifer weiß also beim Schreiben seines Exploits nicht, wo er die für den Angriff benötigten Funktionen und Code-Fragmente findet, was einen erfolgreichen Angriff schwierig macht.
ASLR wird von den aktuellen Versionen aller wichtigen Betriebssysteme unterstützt.
Auch ASLR lässt sich natürlich umgehen. Wie, erfahren Sie in der nächsten Folge.
Ü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 : 0-Day-Schwachstelle in Microsoft Graphics betrifft Office und Windows
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : 0-Day-Exploit für Internet Explorer entdeckt
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Microsoft Graphics: Eine 0-Day-Schwachstelle, mindestens zwei Angriffe
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Der 0-Day-Patchday am 10.12.2013: 4x Microsoft, 1x Adobe
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 : Die erste 0-Day-Schwachstelle 2014 befindet sich im Flash Player
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 : Dritter 0-Day-Exploit für den Internet Explorer in 2014 entdeckt
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: Mobile Technology 3.2014 - Androids Sicherheit aus Forschersicht
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 : Neues eBook: Android Security - Von Fake-Apps, Trojanern und Spy Phones
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Microsoft patcht, und wieder sind 0-Day-Schwachstellen dabei!
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Der Juli-Patchday war ein 0-Day-Patchday
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 10.15 - Wie sicher ist C# 6.0?
Vorschau anzeigen
entwickler.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.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 1.16 - Edge und die Sicherheit
Vorschau anzeigen
entwickler.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 7.16 - Alles im Fluss?
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 11.17 - Windows 10 im Visier der Sicherheitsforscher
Vorschau anzeigen