Praktikum Internet-Sicherheit: Aufgabe zu Buffer-Overflow Attacken

Transkript

1 Zürcher Hochschule Winterthur (ZHW) Bericht Projektarbeit 2 Praktikum Internet-Sicherheit: Aufgabe zu Buffer-Overflow Attacken Studiengang Informationstechnologie Studenten: D. Bischoff, P. Gossweiler, M. Vergari Betreuer: Marc Rennhard 17. Mai Juli 2005

2 Inhaltsverzeichnis 1 Zusammenfassung 4 2 Abstract 5 3 Aufgabenstellung Einführung und Motivation Aufgabenstellung Bemerkungen Einleitung Projektangaben Zweck dieser Projektarbeit Zum Bericht Anmerkungen zum Aufbau des Berichts Verwendete Software Projektplanung Zeitplan Speicherorganisation Segmente Stack Buffer-Overflows Buffer-Overflow-Schwachstellen Typen Erste Generation - Stack-Overflow Angriffsmöglichkeiten Zweite Generation - Off-by-Ones und Frame Pointer Overwrites Dritte Generation - BSS Overflows Vierte Generation - Heap-Corruption Format-String Attacken Die Schwachstelle Angriffsmöglichkeiten Gegenmassnahmen Ursachenbekämpfung Sichere Programmierung Source Code Audit Automatisierte Software-Tests D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

3 Binary Audit Bekämpfung der Auswirkungen Compiler Erweiterungen Wrapper für unsichere Bibliotheksfunktionen Modifikation der Prozessumgebung Fazit Praktikum Überlegungen zu den Aufgaben Konfiguration Aufgabe Aufgabe Lösung Schlusswort 54 A GDB-Befehlsliste 55 B Inhalt der beiliegenden CD 57 C Quellcode 58 C.1 Aufgabe C.2 Aufgabe Literaturverzeichnis 65 D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

4 1 Zusammenfassung Sicherheit spielt in der heutigen Kommunikationsgesellschaft eine sehr grosse Rolle. Regierungen, Firmen und auch Private speichern wichtige Daten in digitaler Form auf Computersystemen ab. Viele dieser Systeme sind, direkt oder indirekt, mit dem Internet verbunden. Software, die auf solchen Systemen läuft, muss betreffend Sicherheit und Zuverlässigkeit hohe Anforderungen erfüllen. Sie muss garantieren, dass nur befugte Benutzer Zugriff erhalten. Ausserdem sollte sie möglichst robust und zuverlässig arbeiten. Eine der populärsten Methoden, um Systeme anzugreifen oder unbefugten Zugriff zu erhalten, ist die Buffer-Overflow Attacke. Obwohl heute allseits bekannt, tauchen doch immer wieder Schwachstellen dieses Typs in bekannten Softwareprodukten auf. Aus diesem Grund soll an der ZHW im Rahmen eines Praktikums auf die Thematik aufmerksam gemacht werden. Ziel der Projektarbeit war es, sich in die Thematik Buffer-Overflow einzuarbeiten und das erarbeitete Wissen in Form eines Praktikums den Studierenden der ZHW zugänglich zu machen. Zum Thema Buffer-Overflow finden sich im Internet unzählige Informationsquellen. Die verschiedenen Typen von Buffer-Overflow-Schwachstellen haben wir analysiert und in diesem Bericht zusammengefasst. Aus den gewonnenen Erkenntnissen haben wir dann Praktikumsaufgaben erarbeitet. Dabei haben wir darauf geachtet, dass der Student möglichst ohne grosse Vorkenntnisse die Aufgaben selbstständig durcharbeiten kann. Dadurch vergrössert sich der Lerneffekt und die Studierenden können die Lektion mit einem Aha-Erlebnis verlassen. Bei Buffer-Overflows handelt es sich um eine aktuelle und schwerwiegende Klasse von Software- Schwachstellen, die wohl auch in naher Zukunft nicht an Bedeutung verlieren wird. Mit dieser Projektarbeit wollen wir das Bewusstsein für diese Art von Schwachstelle stärken. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

5 2 Abstract In todays society information security plays an important role. Governments, companies and individuals save their valuable data in digital form on computer devices. Many of these systems are, directly or indirectly, connected to the internet. Therefore software that runs on such systems has to meet very high standards in security and reliability. It has to guarantee that only authorized users get access and it has to be robust and reliable. One of the most popular methods to attack systems or get unauthorized access is the buffer overflow attack. Although well known today, such vulnerabilities still appear in modern software products. For this reason the Zurich University of Applied Sciences Winterthur (ZHW) wants to increase the awareness of that problem. Goal of this project thesis was to get familiar with the topic and to design exercices for a practical course to make the gained knowledge accessible to other students. A lot of information about buffer overflows can be found on the internet. We analyzed the various types of buffer overflow weaknesses and summarized them in this report. With our findings we developed the exercises. We paid special attention that the students are able to work through the exercises independently and without advanced knowledge. This magnifies the learning effect and the student can leave the lesson with an aha-experience. Buffer overflows are still a actual and serious kind of software weaknesses that won t disappear in the near future. This project thesis should help increase the awareness of such flaws. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

6 3 Aufgabenstellung 3.1 Einführung und Motivation Für das WS 2005/06 soll das bisherige SNK-Praktikum neu konzipiert werden. Das Ziel dieser PA ist die komplette Ausarbeitung eines Praktikumversuchs. Thematisch wird sich der Versuch im Bereich Buffer-Overflow Attacken bewegen. Buffer-Overflow Attacken sind heute die häufigste Art, wie sich nicht- -basierte Viren und Würmer verbreiten. Ein Buffer- Overflow tritt auf, wenn ein Programm oder Prozess mehr Daten in einem temporären Buffer speichern will als vorgesehen. Die zusätzlichen Daten werden dabei nicht einfach verworfen, sondern werden in die dem Buffer folgenden Positionen in den Speicher geschrieben. Dadurch können andere, gültige Daten im Speicher überschrieben werden. In einer Buffer-Overflow Attacke wird genau dies ausgenützt. Dabei enthalten die zusätzlichen Daten ausführbaren Code um spezifische Aktionen auszulösen, zum Beispiel um das Filesystem zu beschädigen oder um Zugriff auf sensitive Information zu erhalten. 3.2 Aufgabenstellung Im Rahmen dieser PA soll eine komplette Praktikumsaufgabe zum Thema Buffer-Overflow Attacken konzipiert, aufgebaut, ausgetestet und dokumentiert (inklusive der Praktikumsanleitung für die Studierenden) werden. Die Aufgabenstellung beinhaltet folgende Punkte: Machen Sie sich mit der Thematik um Buffer-Overflow Attacken vertraut, damit Sie genau wissen, was es mit dieser Familie von Attacken auf sich hat. Sie finden unzählige Ressourcen zum Thema im Web. Konzipieren Sie eine interessante Praktikumsaufgabe für die Studierenden, welche in Zweiergruppen an einem Praktikumsnachmittag (4 Lektionen) sinnvoll lösbar ist. Nach Möglichkeit sollen die Aufgaben bewertbar sein, ähnlich, wie Sie des bereits aus dem aktuellen SNK-Praktikum kennen. Setzen Sie die Aufgabe um und testen sie. Schliesslich erstellen Sie auch noch die Praktikumsanleitung für die Studierenden. Die Aufgabe soll unter Linux implementiert werden. Weil Buffer-Overflows mit Programmiersprachen wie Java nicht möglich sind, werden Sie benötigte Software in C (oder C++) entwickeln. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

7 3.3 Bemerkungen Organisieren Sie sich die benötigten Hard- und Softwarekomponenten selbst. Ihre Ansprechspartner hierfür sind Markus Rohner (E222) und Andreas Schmid (E405). Mit dem Betreuer werden regelmässige Meetings abgehalten um den Fortlauf der Arbeit und offene Fragen zu besprechen. Nach der ersten Woche müssen die Studierenden einen Arbeitsplan erstellt haben, der die Tätigkeiten während der gesamten Projektarbeit inklusive der wichtigsten Milestones erläutert. Dieser Plan ist mit dem Betreuer zu besprechen. Es ist ein schriftlicher Bericht zur Projektarbeit zu erstellen. Der Bericht kann in Deutsch oder Englisch sein und muss einen Abstract sowohl in Deutsch als auch Englisch enthalten. Der Bericht muss alle während der Arbeit durchgeführten Schritte und Gedankengänge klar und nachvollziehbar beschreiben. Dem Bericht ist ebenfalls eine CD-ROM beizulegen, welche den Bericht im pdf-format enthält. Es ist wichtig, dass die in der Arbeit entwickelten Softwarekomponenten und Systeme auch später wieder verwendet werden können. Deshalb muss der Bericht die notwendigen Informationen enthalten (verwendete Hardware, Software, Versionen etc.), um die Systeme eindeutig zu reproduzieren. Sämtliche während der Arbeit entwickelte Softwarekomponenten und Konfigurationsfiles sind der CD-ROM beizufügen. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

8 4 Einleitung 4.1 Projektangaben Projektname: Dozent: Studierende: Praktikum Internet-Sicherheit: Aufgabe zu Buffer-Overflow Attacken Marc Rennhard Daniel Bischoff Philip Gossweiler Marco Vergari Termine: Starttermin: 17. Mai 2005 Endtermin: 01. Juli 2005 Die Arbeit wurde im Rahmen einer Projektarbeit für Informatik-Studierende an der Zürcher Hochschule Winterthur durchgeführt (PA2 Rer 05/4). 4.2 Zweck dieser Projektarbeit In dieser Projektarbeit ging es um die Realisierung eines Praktikum mit dem Thema Buffer- Overflow Attacken. Es zeigt den Studierenden anhand verständlicher Beispiele wo ein Buffer- Overflow auftreten kann und wie man ihn ausnutzen kann. Neben dem Praktikum für die Studenten ist ein Theorieteil erarbeitet worden, welcher die verschiedenen Arten von Buffer-Overflow und deren Gegenmassnahmen zeigt. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

9 4.3 Zum Bericht Bei diesem Bericht handelt es sich um einen Fachbericht. Daher werden allgemein bekannte Fachbegriffe nicht ins Deutsch übersetzt. Weiter wird davon ausgegangen, dass der Leser mit der Programmiersprache C vertraut ist Anmerkungen zum Aufbau des Berichts Kapitel 3 beinhaltet die offizielle Aufgabenstellung für die Projektarbeit Kapitel 6 behandelt die zum Verständnis von Buffer-Overflow Attacken notwendigen Systemkenntnisse In Kapitel 7 werden schliesslich die verschiedenen Varianten von Buffer-Overflow Attacken erläutert Kapitel 8 enthält die von uns erarbeiteten Praktikumsaufgaben Verwendete Software C-Compiler: gcc Debugger: gdb 6.1 OS: SuSE Linux 9.1 D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

10 5 Projektplanung 5.1 Zeitplan Für diese Projektarbeit standen insgesamt sieben Wochen zur Verfügung. Ausgabedatum der Projektarbeit war der 17. Mai 2005, Abgabetermin war der 1. Juli Wir teilten uns diese sieben Wochen folgendermassen ein: Woche 1 Woche 2 Woche 3 Woche 4 Woche 5 Woche 6 Woche 7 1. Einarbeiten in die Theorie: Da das Thema Buffer-Overflow noch relativ neu für uns ist, müssen wir uns zuerst individuell in das Thema einarbeiten. Dazu haben wir uns bereits im Vorfeld geeignete Literatur besorgt. Diese werden wir in den ersten drei Wochen der Projektarbeit studieren. 2. Aufbereiten der Theorie: Da wir im Rahmen dieser Projektarbeit eine Dokumentation der von uns erarbeiteten Kenntnisse erstellen sollen, müssen wir uns einen Überblick über die relevanten Themengebiete verschaffen. Wir werden die Mengen an Informationen zusammenfassen und gegebenenfalls für die Dokumentation aufbereiten. Darauf werden wir uns in der dritten und vierten Woche konzentrieren. 3. Praktische Beispiele finden: Zu Buffer-Overflow findet man Unmengen an Beispielen. Diese wollen wir analysieren. Es sollen in diesem Schritt auch Abhängigkeiten von Linux-Distributionen und Compilern geprüft werden. 4. Ausarbeiten des Praktikums: Aufgrund der gewonnenen Erkenntnisse sollte es uns nun möglich sein, sinnvolle Praktikumsaufgaben zu definieren. Die Aufgaben sollen von IT- als auch von KI-Studierenden gelöst werden können. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

11 5. Praktikums-Aufgabenstellung: Die Praktikumsaufgabe muss in einer kurzen, vollständigen Anleitung für die Studenten beschrieben werden. 6. Theorie-Dokumentation: Die Dokumentation der Projektarbeit soll die von uns erarbeiteten Kenntnisse festhalten. 7. Reserve: Eine Woche ist als Reserve eingeplant. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

12 6 Speicherorganisation Die folgenden Kapitel geben einen Überblick über die Speicherorganisation in heutigen Systemen. Die Informationen beziehen sich auf die Organisation des Speichers zur Laufzeit (Prozess) und nicht auf das Binärformat eines auf einem Datenträger gespeicherten Programms. Es wird ausserdem genauer auf den Aufbau und die Funktionsweise des Stacks eingegangen, da Buffer-Overflow Attacken in diesem Speicherbereich am häufigsten sind. 6.1 Segmente Dank des virtuellen Speichers steht einem Prozess in heutigen Systemen ein grosser virtueller Adressraum zur Verfügung. Dieser Adressraum wird normalerweise in separaten Regionen organisiert. Diese Regionen nennt man Segmente. Folgende Abbildung zeigt ein Beispiel für ein Prozess-Speicher-Layout: hohe Adresswerte Stack dynamisches Wachstum Heap BSS Data Text niedrige Adresswerte Das Text-Segment enthält sämtliche Programmanweisungen, welche durch die CPU ausgeführt werden. Hier befinden sich also die binär kodierten Prozessorbefehle. Das Data-Segment enthält alle globalen Variablen des Prozesses. Bei Variablen handelt es sich um nichts anderes, als um eine benannte Speicherzelle für Daten. Dabei muss zwischen globalen und lokalen Variablen unterschieden werden. Globale Variablen sind von überall her aus dem Programm zugreifbar. Auf Lokale Variablen kann man nur von innerhalb eines bestimmten Blocks (Funktion / Anweisung) aus zugreifen. Das Data-Segment enthält also D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

13 die globalen Variablen, wobei zwischen initialisierten und uninitialisierten Variablen unterschieden wird. Uninitialisierte Variablen werden im BSS-Bereich (Block Started by Symbol) innerhalb des Data-Segments abgelegt, initialisierte Variablen im Data-Bereich. Es ist möglich, während der Programmausführung dynamisch Speicherbereiche zu allozieren. Diese Daten werden im Heap-Segment gespeichert. Zur Allozierung zur Laufzeit wird in C normalerweise die Bibliotheksfunktion malloc() verwendet. Speicherbereich müssen wenn sie nicht mehr gebraucht werden mit free() wieder freigegeben werden. Der Zugriff auf solche dynamisch allozierte Daten erfolgt mittels Zeiger.s Es bleibt noch das Stack-Segment. Es dient zur Speicherung von lokalen Variablen. Diese werden stets neu erzeugt, wenn die Funktion, in der sie deklariert sind, aufgerufen wird, bzw. wieder zerstört, wenn die Funktion verlassen wird. Es ist jedoch auch möglich, eine lokale Variable als statisch (Schlüsselwort static) zu deklarieren. In diesem Fall wird sie entweder im BSS- oder im Data-Bereich des Data-Segments gespeichert. Folgendes Code-Stück zeigt die Deklaration von lokalen und globalen Variablen: int i; int j = 1; //BSS-Bereich im Data-Segment //Data-Bereich im Data-Segment void funktion (void) { int k; static int a; static int b = 2; //Stack-Segment //BSS-Bereich im Data-Segment //Data-Bereich im Data-Segment int main(void) { /* weiterer Code */ In heutigen Betriebssystemen wird für den Zugriff auf die Segmente oftmals nicht die Segmentierungs-Funktion der Prozessoren verwendet. Linux zum Beispiel verwendet das Flat- Memory-Model. Das heisst, dass die Segmentierung im Prozessor nicht aktiviert ist bzw. nur ein grosses Segment existiert. Die Segmente können jedoch mittels Paging im Speicher abgebildet werden. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

14 6.2 Stack Auf dem Stack werden nicht nur die vom Benutzerprogramm benötigten Daten abgelegt. Bevor der Prozess gestartet wird, werden vom Betriebssystem diverse andere Daten auf den Stack gelegt. Folgende Darstellung gibt eine Übersicht: niedrige Adresswerte User Stack Argumentzähler (int) Programmargumente (Zeiger) Umgebumgsvariablen (Zeiger) Programmargumente (Strings) Umgebungsvariablen (Strings) Programmname (nochmals in Argument 0) Endmarke (dword) oberes Stack-Ende hohe Adresswerte Man sieht, dass unter anderem auch Umgebungsvariablen und die dem Programm übergebenen Argumente auf dem Stack liegen. Diese Erkenntnis ist wichtig, wenn man mit Stack- Adressen arbeitet. Nur durch das Vorhandensein einer Umgebungsvariable in der Shell kann sich die Position einer Variable auf dem Stack verändern, wenn man das Programm neu startet. In diesem Abschnitt geht es darum aufzuzeigen was auf Assemblercode-Ebene passiert, wenn ein C-Programm ausgeführt wird. Für das Verständnis von Buffer-Overflow Attacken ist insbesondere das Verständnis von Funktionsaufrufen wichtig. Anhand eines einfachen C- Programms, bestehend aus drei Funktionen, wird schrittweise erklärt, was genau passiert. Dieses Beispiel erhebt nicht den Anspruch eine Aufgabe sinnvoll zu lösen, sondern soll nur als Anschauungsbeispiel dienen. Das folgende C-Beispiel besteht aus den drei Funktionen main(), area() und volume(). main() hat vier lokale Variablen, drei davon werden als Argumente der Funktion volume() übergeben, in der vierten Variable wird der Rückgabewert von volume() gespeichert. Die Aufgabe von volume() ist die Berechnung des Volumens aus den drei übergebenen Argumen- D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

15 ten. Dazu ruft volume() die Funktion area() auf, die aus zwei übergebenen Argumenten zuerst die Grundfläche berechnet und das Resultat dieser Berechnung an volume() zurückgibt. Ausserdem verfügt volume() zusätzlich über eine lokale Variable namens scale, mit der das errechnete Volumen multipliziert wird. int area(int length,int width) { return (length * width); int volume(int length, int width, int height) { int scale = 1; return (area(length, width) * height * scale); int main() { int a, b, c, result; a = 5; b = 2; c = 7; result = volume(a, b, c); return 0; Im Folgenden wird die main() Funktion des C-Programmes auf Assembler-Ebene dargestellt. Dazu eignet sich natürlich ein Debugger, sofern das Programm als Quellcode vorliegt, ansonsten kann auch ein so genannter Disassembler dazu verwendet werden. Zu beachten ist noch, dass je nach verwendetem Compiler unterschiedlicher Code generiert wird. int main() main: { push ebp mov ebp,esp int a, b, c, result; sub esp,10h a = 5; mov dword ptr [ebp-4],5 b = 2; mov dword ptr [ebp-8],2 c = 7; mov dword ptr [ebp-0ch],7 mov push mov push mov push eax,dword ptr [ebp-0ch] eax ecx,dword ptr [ebp-8] ecx edx,dword ptr [ebp-4] edx result = volume(a, b, c); call volume add esp,0ch mov dword ptr [ebp-10h],eax return 0; xor eax,eax mov esp,ebp pop ebp ret In den meisten Programmiersprachen werden lokale Variablen auf dem sogenannten Stack abgelegt. Dieser Stack ist eine LIFO-Datenstruktur (Last In First Out) und wächst von der grösseren zur kleineren Adresse. Die jeweils aktuelle Position auf dem Stack wird durch den sogenannten Stack Pointer angegeben (esp). Wird ein neuer Wert auf dem Stack abgelegt, wird der Stack Pointer zuerst um die notwendige Anzahl Bytes dekrementiert und daraufhin der Wert an dieser neuen Position eingefügt. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

16 Wie auf der unteren Abbildung erkennbar ist, wird als erstes auf dem Stack der Base Pointer (old ebp) abgelegt. Der Base Pointer ist der einzige fixe Bezugspunkt in einem Stack Frame, d.h. er zeigt, einmal gesetzt, im jeweiligen Stack Frame immer an den gleichen Ort. Dieser fixe Bezugspunkt ist notwendig, damit die Variablen auf dem Stack überhaupt adressiert werden können. Dies geschieht dadurch, dass jede Variable als positiver oder negativer Offset bezüglich des Base Pointer angegeben wird, also z.b. als ebp-4. Der Grund wieso dass nicht der Stack Pointer als Bezugspunkt verwendet wird ist relativ einleuchtend, denn jedesmal wenn ein neuer Wert abgelegt wird, ändert sich die Position des Stack Pointers, somit ist dieser als Bezugspunkt ungeeignet. Dies würde bedeuten, dass für jede Variable innerhalb des Stack Frames der Offset angepasst werden müsste, was viel aufwändiger ist. esp ebp-0ch ebp-8 ebp-4 ebp edx(5) ecx(2) eax(7) result(?) c(7) b(2) a(5) old ebp Nachdem nun die alte Position des Base Pointers gesichtert ist, wird die neue Position festgelegt. Dies geschieht durch das Kopieren der aktuellen Adresse im Stack Pointer in den Base Pointer. Somit zeigt der Base Pointer neu auf den Wert des alten Base Pointers. Nun können die lokalen Variablen abgelegt werden. Bei der Sprache C wird verlangt, dass alle lokalen Variablen am Anfang der Funktion deklariert werden. Dadurch kann der Compiler in einem Schritt errechnen, wieviel Platz auf dem Stack benötigt wird. Ist die Anzahl Byte bekannt, kann der Stack Pointer einfach um diese Zahl reduziert werden, wodurch dann der notwendige Speicherplatz alloziert ist. Über den Base Pointer kann jetzt jede der lokalen Variablen mit einem gültigen Wert versehen werden. Da im C-Programm als nächstes ein Funktionsaufruf folgt, müssen die notwendigen Argumente an die Funktion übergeben werden. Dies geschieht ebenfalls über den Stack. Bei C werden die Argumente in umgekehrter Reihenfolge auf den Stack gelegt, also das letzte Argument zuerst. In diesem Beispiel also zuerst c, dann b und schliesslich a. Jetzt folgt der eigentliche Aufruf der Funktion volume(). D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

17 int volume(int length, int width, int height) volume: { push ebp mov ebp,esp int scale = 1; sub esp,4h mov dword ptr [ebp-4],1 mov push mov push eax,dword ptr [ebp+0ch] eax ecx,dword ptr [ebp+8] ecx return (area(length, width) * height * scale); call area add esp,8 imul eax,dword ptr [ebp+10h] imul eax,dword ptr [ebp-4] mov esp,ebp pop ebp ret Wenn eine Funktion aufgerufen wird, muss als erstes auf dem Stack die Rücksprungadresse abgelegt werden. Dies ist notwendig, dass nach dem Funktionsaufruf an die richtige Stelle zurückgesprungen werden kann. Diese Rücksprungadresse ist genau die Adresse des Befehls der jeweils auf den call-befehl folgt. Der Ablauf der Funktion volume() ist analog zum eben beschriebenen Ablauf von main(). Direkt folgend auf das Stack Frame der Funktion main() wird das Frame von volume() aufgebaut. Ein neues Stack Frame bedeutet, dass der Base Pointer für dieses Frame gesetzt werden muss. Somit wird wieder zuerst der vorherige Base Pointer gesichert und daraufhin neu gesetzt. Daraufhin folgen die lokalen Variablen, in diesem Fall ist dies jedoch nur eine Variable namens scale. Schliesslich müssen wieder die Argumente für den nächsten Funktionsaufruf auf dem Stack abgelegt werden. In diesem Fall müssen zwei Argumente (a und b) die bereits an volume() übergeben wurden an die nächste aufzurufende Funktion (area()) weitergeleitet werden. Um diese Argumente kopieren zu können, werden sie bequem über einen Offset zusätzlich zum Base Pointer adressiert. esp ebp ebp+8 ebp+0ch ecx(5) eax(2) scale(1) ebp main ret address edx(5) ecx(2) eax(7) result(?) c(7) b(2) a(5) old ebp Durch den zweiten call-befehl wird nun in die Funktion area() gesprungen. Ebenfalls durch den call-befehl wird wieder die Rücksprungadresse, also die Adresse des auf call folgenden D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

18 Befehls, auf dem Stack abgelegt. int area(int length,int width) area: { push ebp mov ebp,esp return (length * width); mov eax,dword ptr [ebp+8] imul eax,dword ptr [ebp+0ch] mov esp,ebp pop ebp ret Jetzt wird das Stack Frame dieser Funktion aufgebaut. Der Base Pointer wird gesichert, lokale Variablen sind hier keine vorhanden. esp,ebp ebp+8 ebp+0ch ebp volume ret address ecx(5) eax(2) scale(1) ebp main ret address edx(5) ecx(2) eax(7) result(?) c(7) b(2) a(5) old ebp Bei C werden wie bereits erwähnt Argumente auf dem Stack übergeben. Der Rückgabewert einer Funktion hingegen wird im Register eax zurückgegeben. Die beiden Argumente der Funktion müssen nun miteinander multipliziert werden. Dazu wird zuerst der erste der beiden Parameter in eax kopiert und danach mit dem zweiten Parameter multipliziert. Die Aufgabe dieser Funktion ist somit erledigt, da der Rückgabewert berechnet und in eax abgelegt wurde. Das Stack Frame kann also abgebaut werden. Dazu wird in den Stack Pointer der Wert des Base Pointers kopiert. Da hier keine lokalen Variablen vorhanden sind, ändert sich dadurch aber vorerst nichts. Der Stack Pointer zeigt jetzt auf den Base Pointer des vorherigen Stack Frames. Durch den pop-befehl wird dieser wieder in den Base Pointer kopiert. Schliesslich muss noch an den richtigen Ort gesprungen werden. Der Befehl ret holt die abgelegte Rücksprungadresse vom Stack und kopiert diesen Wert in den Instruction Pointer (eip). D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

19 esp esp-4 ebp ebp+8 ebp+0ch esp+10h ecx(5) eax(2) scale(1) ebp main ret address edx(5) ecx(2) eax(7) result(?) c(7) b(2) a(5) old ebp Jetzt befinden wir uns also wieder im Stack Frame der Funktion volume(). Allerdings liegen zuoberst auf dem Stack noch die Argumente für die Funktion area(), diese müssen jetzt entfernt werden. In diesem Beispiel bleibt dies der Funktion überlassen die die andere Funktion aufruft, also derselben Funktion, die die Argumente dort abgelegt hat. Diese Argumente können sehr einfach abgebaut werden indem man den Stack Pointer um die notwendige Anzahl Bytes erhöht (da der Stack von der grösseren zur kleineren Adresse wächst). Schliesslich können auch in dieser Funktion die notwendigen Multiplikationen durchgeführt werden, da in eax der Rückgabewert von area() immer noch vorhanden ist. Der vorherige Rückgabewert in eax kann nun ohne weiteres durch den Rückgabewert von volume() überschrieben werden. Ist auch dies getan wird das Stack Frame der Funktion volume() analog zum vorherigen Frame abgebaut. In der Funktion main() müssen wiederum die Argumente des vorhergegangenen Funktionsaufrufs entfernt werden. Dazu wird auch hier der wiederhergestellte Stack Pointer von main() angepasst. Nun muss noch der Rückgabewert, also der Wert in eax, in der lokalen Variable result der Funktion main() abgelegt werden. Ist dies erledigt, muss an das Betriebssystem der Wert 0 zurückgegeben werden (um zu signalisieren das alles glatt gelaufen ist). Wiederum muss also der Wert in eax geändert werden. Dies geschieht mit dem Befehl xor eax, eax. Der Wert in eax wird also mit sich selber exklusiv-oder verknüpft, dies hat zur Folge, dass der Wert in eax auf 0 gesetzt wird. Natürlich wäre es auch möglich zu schreiben mov eax, 0, die xor-verknüpfung ist jedoch effizienter. Nachdem nun auch der Rückgabewert der Funktion main() gesetzt ist, kann auch dieses letzte Stack Frame abgebaut werden. Ist dies erledigt terminiert das Programm. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

20 7 Buffer-Overflows Dieses Kapitel behandelt verschiedene Varianten von Buffer-Overflow-Schwachstellen. Dabei wird zuerst eine Typisierung eingeführt und die einzelnen Typen dann genauer erläutert. Weiter wird auf mögliche Gegenmassnahmen eingegangen. 7.1 Buffer-Overflow-Schwachstellen Buffer-Overflows (Pufferüberläufe) stellen die in den letzten Jahren wohl am häufigsten ausgenutzten Schwachstellen zur Kompromittierung eines Systems dar. Buffer-Overflows treten immer dann auf, wenn Daten aus externen Quellen (z.b. vom Benutzer) ohne Längenprüfung in einen Buffer mit statischer Länge geschrieben werden. Der Benutzer hat somit die Möglichkeit, dem Programm mehr Daten zu übergeben, als dessen Buffer speichern kann. Die überzähligen Daten gehen dabei nicht verloren, sondern überschreiben die im Speicher nach dem Buffer folgenden Daten. Dabei kann es sich um sensitive Informationen handeln, wie zum Beispiel Zeiger oder auch Informationen zur Steuerung des Programmflusses oder Daten für die Speicherverwaltung. Im Normalfall führt ein solcher Buffer-Overflow zu einem unerwarteten Programmabbruch. Wird der Inhalt der Benutzereingabe jedoch geschickt konzipiert, können gezielt sensitive Bereiche im Speicher überschrieben und dadurch der Programmfluss manipuliert werden. Somit lässt sich zum Beispiel mittels eines Buffer-Overflows beliebiger eingeschleuster Code mit den Rechten des fehlerhaften Programms ausführen. Die im Folgenden vorgestellten Ansätze und Techniken lassen sich vom Prinzip her auf alle Prozessorarchitekturen und alle Betriebssystemplattformen übertragen. Die konkreten Beispiele beziehen sich jedoch auf ELF-basierte UNIX-artige Betriebssysteme (z.b. Linux), sowie die IA-32-Architektur. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

21 7.2 Typen Wie in [1] beschrieben lassen sich Buffer-Overflow-Schwachstellen in verschiedene Typen oder Generationen unterteilen. Generationen deshalb, weil die Schwachstellen in derselben Reihenfolge wie hier aufgelistet bekannt geworden sind. 1. Generation: Klassische Stack-basierte Buffer-Overflows 2. Generation: Off-by-One-Overflows und Frame Pointer Overwrites 3. Generation: BSS-Overflows 4. Generation: Heap-Corruption Diese Buffer-Overflow-Typen werden in den folgenden Kapiteln genauer beschrieben. 7.3 Erste Generation - Stack-Overflow Wie in Kapitel 6.2 gezeigt, werden neben lokalen Variablen auch Verwaltungsinformationen - die Rücksprungadresse sowie der alte Frame Pointer - auf dem Stack gespeichert. Die klassische Stack-basierte Buffer-Overflow-Schwachstelle basiert darauf, diese Verwaltungsinformationen gezielt zu überschreiben. Die Möglichkeit bietet sich zum Beispiel dann, wenn ein lokaler, auf dem Stack liegender Buffer durch einen Benutzer über seine Grenzen hinaus beschrieben werden kann. Dadurch werden die dem Buffer nachfolgenden Stack-Bereiche überschrieben. Im Normalfall führt dies zu einem Programmabbruch. Werden die Verwaltungsinformationen jedoch gezielt überschrieben, kann der Programmfluss manipuliert werden. Für ein praktisches Beispiel siehe dazu die Praktikumsaufgabe 1, Kapitel 8.3. Wie in der Praktikumsaufgabe 1 gezeigt wird, können, wenn beim Kopieren von Speicherinhalten keinerlei Längenprüfungen durchgeführt werden, Speicherbereiche oberhalb der Buffer-Grenze überschrieben werden. Da der Stack von den höheren zu den niedrigeren Adressen wächst, können dadurch Verwaltungsinformationen weiter unten auf dem Stack (bzw. weiter oben im Speicher) verändert werden. Die Wurzel allen Übels ist dabei die Sprache C/C++. So wird zur Laufzeit keine Überprüfung auf das Einhalten von Array-Grenzen oder die Gültigkeit von Zeigerreferenzierungen durchgeführt. Im Beispiel wird zum Kopieren des vom Benutzer übergebenen Arguments die C-Library-Funktion strcpy() verwendet, welche ebenfalls keine Überprüfung hinsichtlich der Grösse des Zielpuffers macht. Es existieren diverse weitere Funktionen, welche dieselbe Problematik beinhalten (siehe Kapitel ). D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

22 7.3.1 Angriffsmöglichkeiten Durch Stack-basierte Buffer-Overflows ergeben sich verschiedene Angriffsmöglichkeiten. Die erste wird in der Praktikumsaufgabe 1 demonstriert. Es handelt sich um die gezielte Modifikation des Programmflusses. Dadurch kann zum Beispiel durch Überschreiben einer Rücksprungadresse an einen beliebigen Ort im Programm gesprungen werden. Es ist ausserdem denkbar, andere Daten auf dem Stack zu überschreiben, die ebenfalls Einfluss auf den Programmfluss haben (zum Beispiel ein Funktionszeiger). Eine weitere Möglichkeit ist ein Denial of Service (DoS) Angriff. Dabei wird im Programm durch Übergabe eines überlangen Arguments ein Segmentation Fault provoziert, welcher zur sofortigen Terminierung des Programms durch das Betriebssystem führt. Denial of Service Angriffe werden oft im Zusammenhang mit einem anderen Angriff verwendet. Will man sich im Netzwerk als jemand anders ausgeben, muss man diesen Jemand zuerst aus dem Netz entfernen. Dies kann gegebenenfalls durch solch einen Denial of Service Angriff erledigt werden. Eine dritte Angriffsmöglichkeit ist das Einschleusen von eigenem Programmcode in ein fehlerhaftes Programm. Diese Technik ist vor allem dann interessant, wenn das fehlerhafte Programm über Superuser-Privilegien verfügt. Der eingeschleuste Code verfügt dann über dieselben Rechte. Ein Exploit, der dazu in der Lage ist, besteht aus zwei Teilen: dem Injection Vector und der Payload. Der Injection Vector wird dabei in einen fehlerhaften Buffer kopiert und ist für die Modifikation des Programmflusses verantwortlich. Beim Payload handelt es sich um den eingeschleusten Code, der zur Ausführung gebracht werden soll. Oftmals wird als Payload ein Shellcode eingesetzt. Bei Shellcode handelt es sich um eine Folge von Anweisungen, die eine Shell (Kommandokonsole) öffnen. Folgende Abbildung zeigt das Ergebnis eines Injection Vectors, der einen Buffer-Overflow auf dem Stack dazu ausnutzt, einen Payload sowie eine neue Rücksprungadresse auf den Stack zu speichern. NOPs Payload (Shellcode) Adresse der Payload Überlaufpuffer old ebp old esp Der Injection Vector schreibt zuerst eine Reihe von nop-befehlen in den Buffer. Bei nop handelt es sich um einen Prozessorbefehl, der das Register eax mit sich selber vertauscht (xchg eax, eax). Der Befehl bewirkt also gar nichts (no operation). nop-befehle werden oft als Platzhalter in Programmen verwendet. Als zweites enthält der Buffer den Shellcode. Dabei handelt es sich wie gesagt um eine Reihe von Prozessorbefehlen, die eine Betriebssystem- Shell öffnen. Nach dem Shellcode wird der restliche Speicher bis zur Rücksprungadresse mit der Adresse des Payloads gefüllt. Man könnte natürlich auch nur die Rücksprungadresse mit der Payload-Adresse überschreiben. Alles zu überschreiben ist jedoch einfacher. Aber wie soll der Exploit nun ablaufen? Wird die Funktion mit der Buffer-Overflow-Schwach- D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

23 stelle verlassen, wird nicht in die aufrufende Funktion, sondern zur Payload-Adresse gesprungen. Das grösste Problem beim Erstellen eines Injection Vectors besteht darin, die Adresse des Payloads auf dem Stack zu bestimmen. Der Stack kann je nach System und Vorhandensein von Umgebungsvariablen an einer anderen Adresse liegen. Aus diesem Grund hat der Injection Vector zuvorderst im Buffer nop-befehle eingefügt. Dadurch wird der Bereich, in den erfolgreich gesprungen werden kann, vergrössert und man kann durch Ausprobieren eine Adresse bestimmen, mit der der Exploit funktioniert. Es wird dann irgendwo in den nop-bereich gesprungen. Die nop-anweisungen werden abgearbeitet und danach wird der Shellcode ausgeführt. Dieser öffnet eine Kommandozeile, die mit den Rechten des fehlerhaften Programms läuft. Payload und Injection Vector könnten auch getrennt verwendet werden. So könnte die Payload über eine Umgebungsvariable in ein Programm eingeschleust werden. Der Injection Vector müsste dann die Rücksprungadresse einer Funktion mit der vermuteten Position der Umgebungsvariablen im Speicher überschreiben. 7.4 Zweite Generation - Off-by-Ones und Frame Pointer Overwrites Unter Off-by-One-Overflows versteht man im Allgemeinen Ein-Byte-Buffer-Overflows. Diese treten oft bei C-Konstrukten der folgenden Art auf: char buff[256]; int i; for (i = 0; i <= 256; i++) { buff[i] = benutzer_eingabe[i]; Im Beispiel wird mittels einer for-schleife der Buffer buff mit einer Benutzer-Eingabe gefüllt. Dabei zählt die Schleifenvariable i von 0 bis und mit 256. Es werden also insgesamt 257 Elemente geschrieben, eines mehr als im Buffer platz ist. Solche Fehler unterlaufen oft Anfängern. Die Tatsache, dass in C/C++ das erste Array-Element mit dem Index 0 angesprochen wird, mag gewöhnungsbedürftig sein. Durch obigen Fehler ist ein Benutzer also in der Lage, ein Byte über den Buffer hinaus zu schreiben. Falls direkt nach dem Buffer ein Zeiger im Speicher liegt, ist es bei Little-Endian-Systemen (z.b. IA-32) möglich, das Least Significant Byte (LSB) gezielt zu überschreiben. Dadurch kann unter Umständen der Programmfluss manipuliert werden. Wenn es sich beim Zeiger nach dem Off-by-One Buffer um einen Funktionszeiger handelt, kann man ggf. allein durch Manipulation des LSB eine andere Funktion aufrufen. Denkbar wäre auch die Manipulation eines Zeigers, der auf einen String mit einem Systembefehl zeigt, der später im Programm ausgeführt wird. Ein spezieller Fall von Off-by-One-Overflows sind die Frame Pointer Overwrites. Diese können dann auftreten, wenn der Off-by-One Buffer unmittelbar am Anfang einer Funktion deklariert wird. Dadurch folgt auf dem Stack der Buffer direkt nach dem gespeicherten Frame Pointer. Man kann dann das LSB des Frame Pointers gezielt manipulieren. Folgende Abbildung veranschaulicht die Schwachstelle: D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

24 kleinste Adresse buff 0x41 0x41 0x41... buff... 0x41 0x41 0x41 0x41 FP IP grösste Adresse Auf dem abgebildeten Stack wurde der Off-by-One Buffer buff komplett mit A s gefüllt. Ein A wurde über den Buffer hinaus geschrieben und überschrieb das LSB des Frame Pointers (ebp). Der Benutzer ist somit in der Lage, den gespeicherten Frame Pointer bis zu einem gewissen Grad selber zu bestimmen. Wenn nun in die aufrufende Funktion zurückgekehrt wird, wird der auf dem Stack gespeicherte Frame Pointer in das ebp-register kopiert. Das heisst, das Stack-Frame der aufrufenden Funktion liegt an der durch den Benutzer manipulierten Adresse. Wenn der Benutzer bestimmen kann, wo das Stack-Frame der aufrufenden Funktion zu liegen kommt, kann er damit auch den Ort der Rücksprungadresse der aufrufenden Funktion bestimmen. Er könnte im Buffer buff eine Adresse ablegen und dann den gespeicherten Frame Pointer so manipulieren, dass diese Adresse von der aufrufenden Funktion als Rücksprungadresse interpretiert wird. Somit kann durch die gezielte Manipulation eines einzigen Bytes der Programmfluss geändert werden. Obwohl bei Off-by-One-Overflows nur ein einzelnes Byte überschrieben wird, können solche Schwachstellen unter gegebenen Umständen also ausgenutzt werden. Ein Problem kann jedoch sein, dass der Adressspielraum sehr klein ist, da nur das Least Significant Byte eines Zeigers geändert werden kann. Auch zu beachten ist, dass bei Big-Endian-Systemen solche Attacken nicht so einfach möglich sind, da dort das Most Significant Byte eines Zeigers überschrieben würde. 7.5 Dritte Generation - BSS Overflows Wie in Kapitel 6.1 gezeigt wird, wird der Speicher eines Prozesses in mehrere Segmente aufgeteilt. Bisher haben wir nur Buffer-Overflows im Stack-Segment betrachtet. Im folgenden Abschnitt geht es um Buffer-Overflows im BSS-Bereich des Data-Segments. Im BSS-Bereich werden wie erwähnt uninitialisierte globale Variablen und statische lokale Variablen abgelegt. Falls es sich bei einer dieser Variablen um einen Buffer handelt, über dessen Grenzen aufgrund einer Buffer-Overflow-Schwachstelle hinausgeschrieben werden kann, können auch im BSS-Bereich sensitive Daten überschrieben werden. Folgt auf den Buffer ein Zeiger (zum Beispiel ein Funktionszeiger), kann dieser gezielt manipuliert werden. Folgendes Code-Beispiel zeigt ein anfälliges Programm: D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

25 int main (int argc, char *argv[]) { static char buff[24], *tmpfile; tmpfile = "/tmp/test.tmp"; gets(buff);... Im Beispiel werden zwei statische, lokale Variablen deklariert. Diese werden im BSS-Bereich des Data-Segments direkt hintereinander abgelegt. Danach wird zuerst der Zeiger tmpfile mit der Adresse eines Strings gefüllt. Darauf wird mit der Funktion gets() eine Zeile von der Standardeingabe gelesen. Es findet dabei keine Überprüfung betreffend der Länge des eingelesenen Strings statt. Wenn der Benutzer nun mehr als 23 Zeichen eingibt, werden Speicherzellen nach buff überschrieben (ein abschliessendes NUL-Zeichen wird ebenfalls geschrieben). Da auf buff direkt der Zeiger tmpfile folgt, kann dieser gezielt überschrieben werden. Wenn nun im späteren Verlauf des Programms die Datei mit dem durch den Zeiger tmpfile referenzierten String als Namen geöffnet wird, kann bei Änderung des Zeigers ggf. eine andere Datei geöffnet werden. Es ist also auch in anderen Segmenten möglich, Buffer-Overflow-Schwachstellen auszunutzen. Der wesentliche Unterschied der oben beschriebenen BSS-Overflows liegt darin, dass im BSS- Bereich des Data-Segments keine Verwaltungsinformationen gespeichert werden. Wie oben gezeigt, kann jedoch auch durch Überschreiben eines normalen Zeigers der Programmfluss geändert werden. Das Prinzip ist daher dasselbe wie bei Off-by-One-Overflows, bei denen im Normalfall ebenfalls nur ein Zeiger des Programms manipuliert werden kann. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

26 7.6 Vierte Generation - Heap-Corruption Beim Heap handelt es sich um einen Speicherbereich, in dem man mittels Bibliotheksfunktionen (malloc(), calloc() und realloc()) dynamisch zur Laufzeit einzelne Speicherblöcke reservieren kann. Auch beim Heap kann, wie beim Stack, ein Buffer-Overflow dazu genutzt werden, Verwaltungsinformationen zu überschreiben und dadurch den Programmfluss zu verändern. Die Organisation des Heaps hängt von den verwendeten Bibliotheksfunktionen ab. Im Folgenden soll der Aufbau des Heaps exemplarisch an der malloc()-implementation der GNU C Library gezeigt werden. Auf dem Heap reservierte Speicherbereiche werden in der Regel als Chunks bezeichnet. Chunks werden durch malloc() erstellt und können mit free() wieder freigegeben werden. Dabei werden zwei aneinander liegende Chunks jeweils zu einem grösseren Chunk zusammengelegt. Folgende Abbildung zeigt einen möglichen Aufbau des Heaps: niedrige Adresswerte allozierter Chunk allozierter Chunk freier Chunk allozierter Chunk freier Chunk Wachsrichtung des Heaps allozierter Chunk hohe Adresswerte Wie man sieht, wächst der Heap in Richtung der grösseren Adressen. Chunks bestehen nicht nur aus den eigentlichen Daten, sondern besitzen auch noch Verwaltungsinformationen, die als Boundary-Tags bezeichnet werden. Dank diesen Boundary-Tags ist es möglich, mittels eines Buffer-Overflows auf dem Heap den Programmfluss zu manipulieren. Folgende Abbildung zeigt den Aufbau eines Chunks: D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

27 chunk prev_size 4 mem size fd PREV_INUSE 4 4 bk 4 nextchunk Daten >=0 Ein Chunk ist in verschiedene Bereiche aufgeteilt. Durch chunk wird der Beginn des Chunks einschliesslich der Boundary Tags gekennzeichnet. Der Zeiger mem wird an das Programm, das den Speicherbereich alloziert hat zurückgegeben. Nextchunk markiert den Beginn des nächsten im Speicher liegenden Chunks an. Folgende Tabelle beschreibt die Felder eines Chunks: Feld prev_size size fd bk Daten Bezeichnung Gibt die Grösse des vorangehenden Chunks an, falls der Chunk unbenutzt ist. Falls der vorangehende Chunk alloziert ist, kann dieses Feld zum Speichern von Daten verwendet werden Grösse des Chunks (Anzahl Bytes von chunk bis nextchunk). Zudem befindet sich hier unter anderen das Statusbit PREV_INUSE, das angibt, ob der vorhergehende Chunk alloziert ist oder nicht. Feld ist nur vorhanden, wenn der Chunk unbenutzt ist. Enthält einen Zeiger auf den nächsten unbenutzten Chunk (Forward Pointer). Feld ist nur vorhanden, wenn der Chunk unbenutzt ist. Enthält einen Zeiger auf den vorherigen unbenutzten Chunk (Back Pointer). Die eigentlichen Daten. Interessant sind hier vor allem die beiden Felder fd und bk. Der Terminus nächster unbenutzter Chunk und vorheriger unbenutzter Chunk beziehen sich dabei nicht auf die physikalische Anordnung der Chunks im Speicher, sondern vielmehr auf die Verwaltung von unbenutzten Chunks auf dem Heap. Diese werden nämlich in so genannten Bins gespeichert, welche eine doppelt verkettete Liste über alle leeren Chunks führen. Ein Bin verwaltet jeweils Chunks in einer bestimmten Grössenordnung. Die Zeiger fd und bk zeigen auf das nächste und das vorherige Element in solch einer doppelt verketteter Liste. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

28 Bin fd bk bk fd Chunk Chunk fd bk bk fd Chunk Wie bereits zu Beginn erwähnt, werden zwei aneinander liegende Chunks jeweils zu einem einzigen Chunk vereinigt. Wird ein Chunk mittels free() freigegeben, wird er der Liste eines passenden Bins hinzugefügt. Falls nun neben dem gerade freigegebenen Chunk ein weiterer unbenutzter Chunk im Speicher liegt, werden diese beiden Bereiche zusammengefügt. Dazu muss der zweite leere Chunk aus seiner Bin-Liste entfernt werden. Dies geschieht durch ein Makro mit dem Namen unlink(), das folgendermassen definiert ist: /* take a chunk off a list */ #define unlink(p, BK, FD) { BK = P->bk; FD = P->fd; FD->bk = BK; BK->fd = FD; Das Makro ändert den Forward Pointer des vorherigen Chunks in der Liste und den Back Pointer des nächsten Chunks in der Liste. Dadurch wird der Chunk aus der Liste entfernt. Wenn man nun den Forward Pointer und den Back Pointer eines Chunks mit eigenen Werten überschreiben würde und den Chunk als unused markieren könnte (mittels des PREV_INUSE-Bits des nächsten Chunk im Speicher), könnte man die Funktionalität des unlink() Makros dazu verwenden, einen beliebigen Zeiger zu überschreiben. Nehmen wir an, auf dem Heap seine drei Chunks vorhanden: D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

29 Chunk b enthält einen Buffer, in den mittels strcpy() ein benutzerdefinierter String kopiert wird. Da strcpy() keine Längenprüfungen durchführt, kann über den Buffer hinaus geschrieben werden. Somit lässt sich das PREV_INUSE-Bit des nächsten Chunks c ändern und damit der Chunk b als unused markieren. Da Chunk b für das System nun leer ist, wird das erste dword im Datenbereich als Forward Pointer und das zweite als Back Pointer interpretiert. Wird nun die Funktion free() auf Chunk a ausgeführt, wird Chunk a mit Chunk b vereinigt, da b ja fälschlicherweise als leer angesehen wird. Dadurch wird das unlink() Makro auf b ausgeführt unter der Annahme, b müsse zuerst aus seinem Bin entfernt werden. Da Forward und Back Pointer von b durch den Benutzer frei wählbar sind, kann durch unlink() ein beliebiger Zeiger überschrieben werden. Anstelle einer Rücksprungadresse kann zum Beispiel ein Zeiger auf eine Bibliotheksfunktion überschrieben werden. Somit wird beim nächsten Aufruf der entsprechenden Funktion an eine benutzerdefinierte Adresse gesprungen, nicht erst bei Funktionsende. Das oben beschriebene Vorgehen hängt stark von der verwendeten malloc() Implementation ab. Die meisten heute verwendeten Implementationen legen jedoch neben den eigentlichen Daten auch Verwaltungsinformationen auf dem Heap ab. Dadurch ist es auch bei anderen Systemen / Bibliotheken möglich, durch Veränderung dieser Informationen den Programmfluss zu manipulieren. Man sieht, dass sich Heap-Overflows vom Prinzip her nicht von gewöhnlichen Stack-basierten Buffer-Overflows unterscheiden. Die Schwachstelle bleibt dieselbe. Es braucht nach wie vor einen Buffer, für den beim Schreiben von Daten keine Längenprüfung durchgeführt wird. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005

30 7.7 Format-String Attacken Format-String-Schwachstellen sind im Vergleich zu Buffer-Overflows eine eigene Klasse von Software-Schwachstellen. Die Schwachstelle kann im Zusammenhang mit Funktionen auftreten, die eine formatierte Ausgabe erlauben. Format-Funktionen erlauben es, eine beliebige Anzahl Variablen und Konstanten beliebiger Datentypen mittels eines Format-Strings auszugeben. Unter C/C++ ist es nicht möglich, zur Laufzeit den Typ einer Variablen zu bestimmen. Deshalb muss in einem Format-String mittels Platzhaltern angegeben werden, wie die übergebenen Variablen interpretiert werden müssen bzw. von welchem Typ sie sind. Das wohl populärste Beispiel einer Format-String-Funktion ist printf(): #include <stdio.h> int printf(const char *format,...); Die Funktion übernimmt einen Format-String (C-String), sowie eine variable Anzahl von Parametern (üblicherweise ausgedrückt durch drei Punkte). Es existiert eine ganze Reihe von Funktionen in der printf Familie, die auf diese Art von Schwachstelle anfällig sind. Der Format-String besteht aus den zwei folgenden Komponenten: Ausgabetext: Normale Zeichen (ausser %). Diese werden direkt in die Ausgabe kopiert. Formatanweisungen: Werden mit einem %-Zeichen eingeleitet. Eine Formatanweisung gibt an, wie der entsprechende Funktionsparameter interpretiert werden soll (von welchem Typ er ist). Nach der Umwandlung wird der erhaltene Wert in die Ausgabe kopiert. Dazu ein kleines Beispiel: int i = 75; char *buff = "Hallo Welt"; printf("zahl: %d, Zeichen: %c, String: %s \n", i, i, buff); Der Format-String enthält drei Formatanweisungen. %d weist die Funktion an, den ersten Parameter in Dezimalnotation auszugeben, %c bestimmt, dass der zweite Parameter als Zeichen ausgegeben wird und %s lässt den C-String buff in der Ausgabe erscheinen. Die Ausgabe sieht folgendermassen aus: Zahl: 75, Zeichen: K, String: Hallo Welt Für weitere Format-Anweisungen siehe ManPage von printf(). Die Zuordnung von Format- Anweisungen zu übergebenen Parametern ist durch deren jeweilige Reihenfolge gegeben. Folgende Darstellung veranschaulicht dies: printf("zahl: %d, Ziffer: %c, String: '%s'\n", i, i, buff); Neben dem Format-String übernimmt printf() eine variable Anzahl Parameter. Dies wird in der Regel durch die Makros va_start, va_arg und va_end aus stdarg.h ermöglicht. Diese Makros erlauben es, Funktionsparameter vom Stack zu beziehen. Dabei wird zu keiner Zeit geprüft, ob ein gelesener Funktionsparameter überhaupt existiert und von welchem Datentyp er ist. Es ist also Sache der Funktion bzw. des Programmierers dies zu bestimmen, da es zur Laufzeit nicht möglich ist. Im Fall von printf() wird die Zuordnung von Funktionsparameter zum Datentyp mittels des Format-Strings gemacht. D. Bischoff, P. Gossweiler, M. Vergari Seite Juli 2005