Dipl.-Inform. Carsten Eilers

Wie bereits erwähnt entstehen Pufferüberlauf-Schwachstellen durch Programmierfehler: Ein Entwickler verzichtet, aus welchen Gründen auch immer, darauf, die Länge von vom Benutzer manipulierbaren Daten zu prüfen, bevor sie in einen Puffer fester Größe kopiert werden. Dementsprechend sind auch die Entwickler dafür verantwortlich, dass es nicht zu Pufferüberlauf-Schwachstellen kommt: Sie müssen die Eingabedaten vor ihrer Verwendung prüfen, werden dabei aber auch von Funktionen unterstützt, die diese Prüfung selbständig durchführen. So weit, so gut. Oder so schlecht, denn es gibt immer wieder Pufferüberlauf-Schwachstellen in den Programmen und Betriebssystemen. Daher stellt sich die Frage: Wie verhindert man, dass so ein Programmierfehler von Angreifern ausgenutzt wird? Das erste Hilfsmittel ist dabei ein digitaler Kanarienvogel:

Ein Kanarienvogel warnt vor dem Pufferüberlauf

Eine Möglichkeit, ein System vor manchen Folgen einer Pufferüberlauf-Schwachstelle zu schützen, besteht im Schutz der auf dem Stack gespeicherten Rücksprungadresse. Dazu wird zwischen den Puffern und der Rücksprungadresse ein zusätzlicher Parameter abgelegt, der sogenannte canary. Im einfachsten Fall kann das zum Beispiel eine Zufallszahl sein. Bevor die Rücksprungadresse verwendet wird, wird der auf dem Stack gespeicherte canary-Wert mit dem erwarteten Wert verglichen. Stimmen die Werte nicht überein, wurde der canary überschrieben und die Rücksprungadresse darf nicht verwendet werden. Im Allgemeinen wird das Programm dann mit einer Fehlermeldung beendet. Der canary-Wert warnt also vor einem stattgefundenen Pufferüberlauf - so, wie früher Kanarienvögel die Bergleute unter Tage vor zu wenig Sauerstoff in der Luft warnten.

Abbildung 1 zeigt den Stack mit dem Canary, Abbildung 2 den Stack nach einem Pufferüberlauf. Der canary-Wert wurde durch den Pufferüberlauf überschrieben. Bevor die Rücksprungadresse verwendet wird, wird der canary-Wert mit dem ursprünglichen Wert verglichen, der Unterschied festgestellt und das Programm vom Betriebssystem mit einer Fehlermeldung beendet.

Abb. 1: Der Stack mit dem Canary	Abb. 2: Der Stack nach einem Pufferüberlauf

Der Schutz des Stacks über einen canary war die erste Schutzmaßnahme, die gegen Angriffe über Pufferüberläufe entwickelt wurde. Seit 1998 gibt es die StackGuard-Patches für den GCC (PDF), 2001 hat IBM mit der Entwicklung des verbesserten Nachfolgers SSP (Stack-Smashing Protector) begonnen. 2000 wurde für Linux die gcc-Erweiterung StackShield veröffentlicht, die ähnlich funktioniert: Bei jedem Funktionsaufruf wird die Rücksprungadresse am Anfang des Datensegments gesichert und vor dem Rücksprung mit der auf dem Stack gespeicherten Version verglichen. Stimmen die Adressen nicht überein, wird das Programm beendet oder die ursprüngliche Adresse restauriert. Der dazu notwendige Code wird von StackShield am Anfang und Ende jedes Funktionsaufrufs eingefügt.

Inzwischen gibt es für alle aktuellen Betriebssysteme und C-Compiler entsprechende Implementierungen eines Stackschutzes. Der lässt sich natürlich, so wie jede Schutzmaßnahme, unter Umständen umgehen. Daher sind heutzutage weitere Schutzmaßnahmen nötig. Eine davon ist die Data Execution Prevention (DEP).

DEP verhindert das Ausführen von Code

Die DEP ist eine Technik, mit der verhindert wird, dass in nur für Daten vorgesehenen Speicherbereichen gespeicherter Code ausgeführt wird. Je nach Prozessor kann dieser Schutz über die Hardware oder nur über die Software realisiert werden. Ist DEP aktiviert, kann nur in explizit entsprechend markierten Speicherbereichen enthaltener Code ausgeführt werden.

Für Windows wurde diese Schutzmaßnahme mit Windows XP SP2 eingeführt. Die Windows-Lösung wird in zwei Artikeln in Microsofts Security Research & Defense Blog ausführlich beschrieben.

Abbildung 3 zeigt den Angriff aus dem Beispiel der vorigen Folge mit nicht als ausführbar markierten Speicher für den Stack (gekennzeichnet durch das "NX" für "Non-eXecutable"): Das System führt die eingeschleusten Befehle nicht aus, sondern bricht das Programm mit einer Fehlermeldung ab

Abb. 3: Der Stack im durch DEP geschützten Speicher

Unabhängig davon, ob der DEP-Schutz über Hard- oder Software realisiert wird, kann er nur verhindern, dass in Datensegmenten (Stack, Heap etc.) eingeschleuster Code ausgeführt wird. Der Pufferüberlauf findet trotz DEP statt. Wenn der Angreifer es dabei schafft, in das Programmsegment zu springen, kann er dort natürlich Code ausführen. Wie so ein Angriff funktioniert und welche Schutzmaßnahmen es dagegen gibt, wird in der nächsten Folge beschrieben.

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