Dipl.-Inform. Carsten Eilers

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.

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