Die Buffer-Overflow-Problematik

Transkript

1 Die Buffer-Overflow-Problematik WPF-Projekt Codierung und Datensicherheit Wintersemester 01/02 Frank Dopatka Technische Informatik VII

2 Inhaltsverzeichnis Seite 1. Motivation 3 2. Aufgabenstellung und Zielsetzung 4 3. Die Buffer-Overflow-Problematik Funktionsweise der Buffer-Overflows Allgemeines zu Würmern und Trojanern Techniken der Buffer-Overflows Die Array-Überschreitung in C Der Stack-Overflow Der Heap-Overflow Historische Betrachtung Der erste Buffer-Overflow-Angriff Weitere bedeutende Attacken Betrachtung der angreifbaren Software Vergleich von properitärer und open-source Software Maßnahmen zur Vermeidung von Buffer-Overflow-Angriffen Abschließende Anmerkungen Anhang shellcode -Beispiel registrierte Buffer-Schwachstellen gängiger Software Abbildungsverzeichnis Literaturverzeichnis 43

3 1. Motivation Seite 3 1. Motivation Das Internet wird nie sicher sein. [...] Das Internet ist die komplexeste Maschine, die je von Menschenhand gebaut wurde, also wird es auch Unfälle geben. Wir sind ein großes Netzwerk und die Dinge, die einen von uns betreffen, betreffen bald auch andere. 1 Mit diesen Worten des Sicherheits-Experten Bruce Schneider begann die Eröffnung der Information Security Solutions Europe, kurz ISSE-Konferenz in London. Da mittlerweile jedes mittelständige Unternehmen einen Internet-Zugang besitzt und der Trend sogar dahin führt, daß jedes Unternehmen, das zukunftsträchtig sein will, auch einen eigenen Webserver besitzt, nimmt auch die Internet-Kriminalität eine neue und bedrohlichere Form an. Alle größeren Unternehmen kaufen Sicherheits-Software, um ihre MAIL - und WEB-Server, ihr Intranet und damit ihre Firmendaten zu schützen. Online-Shops sind sogar von ihren WEB-Servern so abhängig, daß der Ausfall der Server ihren finanziellen Ruin mit sich bringen würde. Fremd-Unternehmen verdienen ihr Geld ausschließlich damit, diesen geplagten Unternehmen Sicherheitskonzepte vorzustellen und die oben genannte Software zu verkaufen. Damit diese Software ihre Effizienz entfaltet, muß sie von geschultem Personal bedient werden. Aus diesem Grunde dringt die Internet-Problematik auch in die Hochschulen, wie die FH Gummersbach, ein. Auch von dort aus sollen schon Angriffe gestartet worden sein. In der Informatik werden neue Fächer, wie Codierung und Datensicherheit und Technische Aspekte des E-Commerce geboren. Diese Entwicklung motivierte mich schließlich dazu, solche Fächer zu wählen, um eine weitere Grundlage für meinen späteren beruflichen Fortschritt zu legen. Schon bei meinem Praxissemester, das sich mit der Entwicklung einer Authentifizierung über das Internet beschäftigte, stellte ich fest, daß es sinnvoll für ein sicheres Produkt sein kann, sich zu überlegen, wie man es angreifen könnte. Nur wenn man weiß, über welche Mittel Hacker verfügen, ist man in der Lage, präventive Gegenmaßnahmen einzuleiten. Dies wiederum brachte mich dazu, im Fach Codierung und Datensicherheit ein Thema zu wählen, das sich mit einer solchen Angriffs-Methode beschäftigt, dem Buffer- Overflow. So entstand diese Ausarbeitung

4 2. Aufgabenstellung und Zielsetzung Seite 4 2. Aufgabenstellung und Zielsetzung Meine Aufgabe wird es sein, mich zunächst über die Funktionsweise einer Buffer- Overflow-Attacke zu informieren und sie im Kontext zu anderer Malware zu sehen. Ich werde versuchen, diese Funktionsweise nach Möglichkeit allgemein verständlich und anschaulich zu präsentieren, ohne daß die notwendige Tiefe des Themas verlorengeht. Da diese Angriffsart schon älter ist, der erste größere Angriff ist bereits 1988 bekannt geworden, wird sicherlich auch eine historische Betrachtung auf Interesse stoßen. Scheinbar ist es bis heute niemandem gelungen, effiziente Maßnahmen gegen einen Buffer-Overflow zu finden. In einer neuen Studie des Oregon Graduate Institute of Science & Technology heißt es, daß der Buffer Overflow das größte Sicherheitsproblem im Internet darstellt. 2 Ferner werde ich die bekannte Empfindlichkeit heutiger Systeme gegen diese Attacke untersuchen, wobei properitäre Software der open-sorce Software gegenübergestellt wird. Schließlich will ich am Ende des Hauptteils einige Anregungen vermitteln, wie man sich präventiv, sowohl als Benutzer, als auch als Entwickler von Software, vor Buffer- Overflows schützen kann. Abschließend werde ich meine Ergebnisse in einem Review zusammenfassen und kritisch begutachten. Das Ziel dieser Ausarbeitung ist es natürlich nicht, eine Anleitung zum Programmieren von Malware zu liefern. Statt dessen will ich dem Leser einen tieferen Einblick in eine gezielte Schwachstelle der Internet-Sicherheit gewähren. Mit dieser Absicht will ich sowohl dem Leser selbst, wie auch den Produkten, welche der Leser später einmal entwickeln wird, die Möglichkeit zum Schutz gegen diese Angriffe geben. Grundlage dafür ist es, die Schwachstelle zunächst einmal für sich zu realisieren und im Anschluß daran zu vermitteln, wie ein Angriff diese Schwachstelle ausnutzt. Die Anregungen zum Schutz gegen eine Buffer-Overflow-Attacke sind selbstverständlich nicht ausreichend, um sich 100%ig zu schützen. Sie stellen lediglich eine Grundlage dar, sich vor den schwerwiegendsten Fehlern zu schützen und sollen zu einer weiteren Auseinandersetzung mit diesem Thema motivieren. 2 vgl.:

5 3. Die Buffer-Overflow-Problematik Seite 5 3. Die Buffer-Overflow-Problematik Funktionsweise der Buffer-Overflows Bei einer Buffer-Overflow-Attacke überflutet der Angreifer ein Array mit mehr Daten, als es vom Programmierer der Software vorgesehen wurde. Daran läßt sich schon erkennen, daß diese Attacke auf Unzulänglichkeiten des anzugreifenden Programms ausgerichtet ist. Das einfachste Ziel eines Buffer-Overflows ist es, das angegriffene Programm, z.b. einen WEB-Server, außer Betrieb zu setzen. Dabei handelt es sich also um eine sogenannte Denial-of-Service-Attacke (DoS). Ferner dürfte es nicht schwierig sein, den gesamten Rechner zum Absturz zu bringen. Wie aus der Windows-Welt bereits bekannt ist, sind die einzelnen Prozesse nicht völlig unabhängig voneinander. Daher kann der Absturz des WEB-Servers durchaus einen völligen Stillstand des PCs mit sich bringen. Eine Fernwartung wird somit unmöglich. Bei einem DoS genügt es, das betreffende Array mit irgendwelchen Daten zu überladen. Ein Buffer-Overflow kann jedoch wesentlich mehr erreichen: Ein Array besteht bekanntlich aus einem Speicherbereich, sowie aus einem Pointer, der auf ein Element dieses Speicherbereiches zeigt. Mit dem Pointer kann ein Wert aus der Speicherstelle gelesen oder auch in die Speicherstelle geschrieben werden. Zeigt dieser Pointer nun unbemerkt auf eine andere Speicheradresse, so kann diese auch gelesen oder geschrieben werden. Man bekommt also Zugriff auf den Arbeitsspeicher des angegriffenen Rechners. Dort kann sich z.b. das Paßwort befinden, mit dem sich der letzte lokale User eingeloggt hat. Dies kann einfach ausgelesen werden. In diesem Speicher werden auch assemblierte Programme gestartet. Was spricht also dagegen, ein eigenes Programm in das RAM des Zielrechners einzupflanzen und anschließend mit dem Array-Pointer auf die Startadresse des Programms zu zeigen? Das Programm würde dann lokal auf dem Zielrechner ausgeführt. Dies ist der Grund dafür, daß die Buffer-Overflow-Technik gezielt für die Programmierung von Würmern oder Trojanern verwendet wird. Ich werde also zunächst auf die Definition der Begriffe Würmer und Trojaner eingehen und anschließend, in , die oben genannte Vorgehensweise näher erläutern und weiter differenzieren Allgemeines zu Würmern und Trojanern Sowohl Würmer, als auch Trojaner, fallen unter den Begriff der Malware, eine Abkürzung des Begriffes Malicious Software. Diese besondere Software wird bewußt dazu entwickelt, um Schaden an Computern oder Netzwerken zu verursachen. Bei einem Wurm handelt es sich um ein Programm, dessen einzige Aufgabe es ist, sich selber zu reproduzieren und zu verbreiten. Im Gegensatz zu einem Virus infiziert ein Wurm keine anderen Programme und ist auf die Verbreitung in Netzwerken ausgerichtet. Den ersten Internet-Wurm brachte Robert Morris 1988 in Umlauf. Sein Programm legte über 6000 Computer lahm, weil sie nur noch mit der Verbreitung des

6 3. Die Buffer-Overflow-Problematik Seite 6 Wurms beschäftigt waren. 3 Als aktuelles Beispiel kann der im September 2001 aufgetretene -Wurm Nimda genannt werden, der Sicherheitslücken im Microsoft Internet Information Servers (IIS) ausnutzt und offene Netzwerkfreigaben erstellt. So kann unter anderem der Gast-Account von Windows in die Administrator-Gruppe befördert werden. 4 Ein Trojanisches Pferd, kurz Trojaner, erscheint als vermeintlich nützliches Programm, etwa als Utility. So getarnt, wird es von arglosen Anwendern verbreitet und benötigt daher keinen eigenen Replikationsmechanismus. Trojaner werden bevorzugt eingesetzt, um Daten auf fremden Rechnern auszuspähen. Aber auch für jede andere Form der Datenmanipulation lassen sie sich einsetzen. 5 Ein klassisches, wenn auch wenig verbreitetes Beispiel für einen Backdoor-Trojaner ist Iwantyou. Er verwendet den TCP-Port 1722, spioniert Paßwörter aus und versendet diese via Techniken der Buffer-Overflows Wie schon erwähnt, arbeitet Malware auf der Basis von Buffer-Overflows vorwiegend im RAM des Rechners und nutzt Schwachstellen aktiver Programme aus. Eine Ursache für die weite und dauerhafte Verbreitung dieser Technik liegt sicherlich in der Tatsache, daß die 1983 von AT&T entwickelte und weit verbreitete Programmiersprache C keine Überprüfung der Array-Grenzen, das sogenannte bound-checking, durchführt. 7 Man unterscheidet prinzipiell zwei Techniken zur Programmierung von Buffer-Overflows, den Stack-Overflow und den Heap-Overflow. Dabei ist es zunächst hilfreich, den Unterschied zwischen Stack und Heap zu erläutern. Abb. 1: Der Stack und die Heap 8 3 vgl.: vgl.: vgl.: vgl.: vgl.: Script Algorithmen I, Prof. Dr. Frank Victor, FH Köln, Abt. Gummersbach; WS 1998/99, S

7 3. Die Buffer-Overflow-Problematik Seite 7 Der Data-Bereich enthält zunächst einmal die initialisierten globalen statischen Daten, während das BSS-Segment die nicht initialisierten globalen Daten enthält. Diese beiden Bereiche werden bereits beim Kompilieren reserviert, da ihre Größe bekannt ist. Die lokalen und dynamischen Daten kommen in einen Bereich, der für die Ausführung des Programms reserviert ist (user stack frame). Da Funktionen rekursiv aufgerufen werden können, ist die Anzahl der benötigten lokalen Variablen erst einmal nicht bekannt. Sie befinden sich im Stack. Der Stack liegt über der höchsten Adresse im user address space und funktioniert nach dem LIFO- Modell (Last In, First Out). Der untere Teil des user frame Bereiches wird für dynamische Variablen benutzt. Diesen Bereich nennt man Heap. Er enthält den Speicherbereich, der über Pointer adressiert wird sowie die dynamischen Variablen. Beim Deklarieren ist ein Pointer 32bit breit und liegt im BSS oder Stack und zeigt auf nichts. Beim Alloziieren erhält der Pointer die Adresse des ersten Bytes des Wertes im Heap Array-Überschreitung in C Den mangelnden Schutz von Arrays in C läßt sich in einem einfachen Beispiel nachweisen. Selbst in der aktuellen Version, Microsoft Visual C++ 6.0, ist folgendes Beispiel ohne eine Fehlermeldung möglich: int Element[5]; int i; for (i = 0; i < 5; i++) { Element[i] = i; } Abb. 2: Anlegen eines Array in C Der oben dargestellte Quellcode erzeugt im Arbeitsspeicher des Rechners die folgende beispielhafte Struktur: Wert Adresse Beschreibung 0 $CF00 Element 0 1 $CF04 Element 1 2 $CF08 Element 2 3 $CF0C Element 3 4 $CF10 Element 4? $CF14? Abb. 3: Array im RAM des Rechners Ein Zugriff auf das dritte Element geschieht durch x=element[3]. Dabei wird der Array-Pointer auf Element 3 gesetzt. Anschließend wird der Wert des Speicherbereiches, hier $CF0C, ausgelesen. Die Variable x bekommt also den Wert 9 vgl.:

8 3. Die Buffer-Overflow-Problematik Seite 8 3. Was geschieht jedoch, wenn man x=element[5] versucht? Schreibt man dasselbe Programm in Microsoft Visual Basic 6.0, erscheint folgender Fehler: Abb. 4: Arrayüberschreitung in Visual Basic Bei Visual C++ bekommt x den Wert Beim nächsten Mal kann x einen anderen Wert erhalten. Es wird lediglich der Wert ausgelesen, welcher in unserem Beispiel in $CF14 enthalten ist. Man kann natürlich auch x=element[1060] ausführen. Interessanterweise ist x=element[1061] unter Windows XP nicht möglich. Abb. 5: Fehlermeldung bei großem Overflow in Windows XP Die Überschreitung wird jedoch nicht von dem C-Compiler, sondern vom Betriebssystem abgefangen. Man hat scheinbar die Umgebung des Programms verlassen. Dies hat das Betriebssystem alarmiert, wodurch der Zugriff unterbunden und das Programm abgebrochen wurde. Wird das Programm unter anderen Betriebssystemen ausgeführt, muß dies nicht der Fall sein. Dann könnte das gesamte RAM des PCs ausgelesen werden. Nun stellt sich eine weitaus erschreckendere Frage: Ist auch Element[5]=4711 möglich? Kann man also auf Speicherstellen auch schreibend zugreifen, auf die man gar nicht zugreifen darf? Die Antwort lautet: Nicht so einfach unter Windows XP. Man erhält die gleiche Fehlermeldung wie in Abb. 5. Windows 2000 und Windows 98SE verhalten sich ähnlich. Aber auch hier wird der Fehler vom Betriebssystem, und nicht vom Compiler der Programmiersprache abgefangen. Bei Windows 98SE läßt sich beim

9 3. Die Buffer-Overflow-Problematik Seite 9 Versuch des Herunterfahrens ein überraschender Effekt feststellen. Es erscheint folgende Meldung: Abb. 6: Fehlermeldung bei großem Overflow in Windows 98SE Dabei habe ich das ansonsten stabile Windows 98SE hochgefahren, unmittelbar das C-Testprogramm ausgeführt und wollte Windows nach der Quittierung des unerlaubten Zugriffes durch das Testprogramm wieder herunterfahren. Das Testprogramm erschien beim Versuch des Herunterfahrens übrigens nicht mehr im Task-Manager. Um welche Anwendung es sich in Abb. 6 handelt, bleibt unklar. Es ist jedoch sehr wahrscheinlich, daß das Testprogramm den Schreibzugriff trotz der Fehlermeldung durchgeführt hat und dadurch die Speicherverwaltung von Windows 98SE durcheinanderbrachte. Ich denke, daß die Problematik und die möglichen Auswirkungen des fehlenden bound-checking in C dennoch deutlich wurde Der Stack-Overflow Der Stack kann hauptsächlich mit 2 CPU-Befehlen verändert werden. Mit push value reduziert man den Inhalt des Stapelzeigers um ein Wort und speichert den Wert von value auf dem Stack ab. Mit pop dest liest man den Wert aus, auf den der Stapelzeiger gerade zeigt, und erhöht den Inhalt des Stapelzeigers. Der ausgelesene Wert wird in dest gespeichert. Ein Zugriff auf den Stack darf dabei nie die anderen Elemente des Stacks beeinflussen, da ansonsten das LIFO-Prinzip des Stacks verletzt würde. Die anderen Elemente des Stacks könnten ja unter anderem Rücksprungadressen von zuvor aufgerufenen Programmen enthalten, die noch auf ihren Rückgabewert warten. Das Angriffsziel lautet, den Stack eines Prozesses so zu manipulieren, daß seine Rücksprungadresse auf eigenen Assemblercode umgeleitet wird, der nach dem Rücksprung des Prozesses im RAM des Zielrechners ausgeführt wird. Eine einfache Manipulation läuft darauf hinaus, ein Stück Assembler-Code zu generieren, der eine neue Shell startet. Ein detailliertes Beispiel für einen solchen shellcode wird als Referenz-Beispiel für einen Stack-Overflow-Angriff auf UNIX-Maschinen unter

10 3. Die Buffer-Overflow-Problematik Seite genauer betrachtet und analysiert. Ich muß dazu sagen, daß man für einen solchen Angriff selbstverständlich sehr gute Kenntnisse in C und in der Funktionsweise von Assembler- Routinen besitzen muß. So benutzt der Autor dieses Beispiels den GNU-Compiler zur Generierung des Maschinencodes und anschließend gdb, um den resultierenden Assemblercode zu analysieren und zu manipulieren. Ich muß zugeben, daß ich selbst nicht in der Lage bin, jede Einzelheit dieses Beispiels zu verstehen. Im Vergleich zu diesem Beispiel werden meine Versuche zur Erzeugung einer Array-Überschreitung in ausgesprochen naiv und banal aussehen, jedoch kann man an dem Beispiel die logische Vorgehensweise des Autors nachvollziehen und seine Kenntnisse in hardwarenaher Programmierung bewundern ;-) Der Heap-Overflow Prinzipiell ist die Vorgehensweise beim Erzeugen eines Heap-Overflows mit der eines Stack-Overflows identisch. Der Unterschied zwischen dem Stack und der Heap liegt bekanntlich darin, daß in der Heap dynamische Variablen hinterlegt sind. Bei einem Angriff muß man also eine Schwäche bei der Erzeugung dynamischer Variablen ausnutzen. Eine bekannte Schwäche dieser Art liegt im C-Befehl malloc, mit dem ein dynamischer Speicherblock einer bestimmten Größe im Heap alloziiert werden kann. Der Befehl gibt einen VOID -Pointer auf den alloziierten Bereich zurück. Im Gegensatz zu ist dieses Beispiel überschaubarer, weswegen ich es im Folgenden näher analysiere: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #define BUFSIZE 16 #define OVERSIZE 8 /* overflow buf2 by OVERSIZE bytes */ int main() { u_long diff; char *buf1 = (char *)malloc(bufsize), *buf2 = (char *)malloc(bufsize); diff = (u_long)buf2 - (u_long)buf1; printf("buf1 = %p, buf2 = %p, diff = 0x%x bytes\n", buf1, buf2, diff); memset(buf2, 'A', BUFSIZE-1), buf2[bufsize-1] = '\0'; printf("before overflow: buf2 = %s\n", buf2); memset(buf1, 'B', (u_int)(diff + OVERSIZE)); printf("after overflow: buf2 = %s\n", buf2); return 0; } Abb. 7: Beispiel eines Heap-Overflows in C dieses Beispiel befindet sich im Anhang vgl.:

11 3. Die Buffer-Overflow-Problematik Seite 11 Zunächst legt der Programmierer zwei Character-Arrays über den malloc-befehl an, beide von der Größe BUFZIZE. Dadurch wird schon einmal der Speicher für die Arrays reserviert. Anschließend schaut sich der Programmierer an, an welchem physikalischen Speicherplatz die Arrays beginnen. Die Startadressen sind in buf1 und buf2 gespeichert: buf1 = 0x804e000 buf2 = 0x804eff0 Die Differenz der Startadressen ist leicht berechnet mit diff = (u_long)buf2 - (u_long)buf1; und ergibt diff = 0xff0 bytes. Mit memset wird das Array buf2 mit dem ASCII-Wert von A direkt im Speicher gefüllt. Die Zeichenkette wird, wie bei C üblich, mit dem Nullbyte abgeschlossen. Dies ergibt Folgendes: before overflow: buf2 = AAAAAAAAAAAAAAA Der Heap-Overflow wird letztlich in der Zeile memset(buf1, 'B', (u_int)(diff + OVERSIZE)); durchgeführt. Obwohl in das Array buf1 geschrieben werden soll, wird als Startadresse für das Array buf1 letztendlich die Startadresse von buf2 verwendet. Dadurch wird die Integrität des Arrays buf2 verletzt, was zu einer Fehlermeldung führen sollte. Statt dessen sieht buf2 jedoch folgendermaßen aus: after overflow: buf2 = BBBBBBBBAAAAAAA Nun kann man sich vorstellen, daß man anstelle des schreibenden Zugriffs auch einen lesenden Zugriff direkt im RAM durchführen kann, um z.b. Paßwörter auszulesen. Man muß lediglich wissen, wo sie im Speicher stehen. Der Autor gibt noch eine interessante Erläuterung zu diesem Beispiel, der bei meinem eigenen Test in weiterhilft. Er sagt, daß der Heap von buf2 natürlich noch zum reservierten Heap der Anwendung gehört. Innerhalb der Anwendung kann daher in C frei auf den gesamten Heap dieser Anwendung zugegriffen werden. Erst wenn ein Heap-Bereich einer anderen Anwendung verletzt würde, könnte dies vom Betriebssystem erkannt und gemeldet werden. Nun kann man sich weiter vorstellen, daß große, in das Betriebssystem hochintegrierte Software, wie der Internet Information Server von Microsoft, gewisse Schwachstellen bei der Speicherverwaltung aufweist, deren Ausnutzung aufgrund der hohen Integration nicht vom Betriebssystem erkannt werden kann.

12 3. Die Buffer-Overflow-Problematik Seite Historische Betrachtung Der erste Angriff auf der technischen Grundlage des Buffer-Overflows ist, wie in 2. erwähnt, bereits 1988 bekannt geworden. In diesem Kapitel möchte ich die bekanntesten Variationen dieser Angriffstechnik darlegen, um die Brisanz dieser Thematik nochmals hervorzuheben Der erste Buffer-Overflow-Angriff 12 Die Möglichkeit zu einer Buffer-Overflow-Attacke wurde bereits früh als Konsequenz des Daten-Integritätsmodells der Sprache C wahrgenommen. Die erste große Attacke ist 1988 durch einen Internet-Wurm bekannt geworden. Der Befehl fingered benutzt den gets()-call der Sprache C und liest eine Informationszeile ein, für deren Länge 512Byte vorgesehen ist. fingered prüft jedoch nicht, ob die tatsächliche Eingabe 512Byte überschreitet. Wenn dies der Fall ist, kann der stack frame der Subroutine vom Angreifer überschrieben werden. Dieser fingered -Wurm übergab 536Byte an den gets()-call. Die 24Byte an Overflow- Code enthielten Sprachinstruktionen in C für die VAX-Maschine und versuchten, mittels execve( /bin/sh,0,0); auf der VAX eine Shell zu öffnen. Die execve-funktion wird in ähnlicher Weise übrigens im shellcode -Beispiel in 5.1. verwendet Weitere bedeutende Attacken Ursprünglich hatte ich vor, an dieser Stelle eine Liste der bedeutendsten Buffer- Overflow-Schwachstellen seit dem ersten Angriff 1988 anzufertigen. Ich muß jedoch zugeben, daß selbst ich die Ausmaße dieser Angriffs-Methode unterschätzt habe. In einer Internet-Recherche bin ich auf die Seite gestoßen, bei der es sich um eine außerordentlich mächtige und dennoch übersichtliche Plattform zur Aufzeichnung von Internet-Angriffen handelt. Über die interne Such-Funktion gab ich im Archiv 2001 den Suchbegriff Buffer ein und erhielt 110 (!) registrierte bedeutende Software-Schwachstellen inklusive einer Kurzbescheibung zu jedem Problem. Daraufhin habe ich mich dazu entschlossen, nur die wichtigsten 57 Artikel zwischen dem bis zum aufzuführen und zu numerieren. In der Computer- Branche kann bekanntlich ein Jahr durchaus bereits als Historische Betrachtung angesehen werden. Im Folgenden habe ich lediglich die Überschriften aufgelistet, während Sie im Anhang 5.2. die genauere Beschreibung der einzelnen Probleme nachlesen können: 12 vgl: Buffer Overrun Attacks, Paul A. Henry, Cyberguard Corporation

13 3. Die Buffer-Overflow-Problematik Seite 13 01: : Ungeprüfter Buffer in Windows UPnP führt zur PC-Übernahme durch Angreifer 02: : Ernste Schwachstelle in der Login-Prozedur verschiedener Unix-Systeme 03: : Bugs in WS_FTP und WU-FTPD 04: : Weiteres Sicherheitsloch im Windows Media Player aufgetaucht 05: : ActivePerl PerlIS.dll remoter Buffer Overflow 06: : CDE Flaw kann Angriffe ermöglichen 07: : IRIX Printing-System Schwachstellen 08: : Mehrere Bugs und Patches bei Oracle 09: : Linux Popularität zieht Würmer nach sich 10: : CheckPoint FW-1 GUI Buffer Overflow 11: : AOLserver Authorisierungs Buffer Overflow 12: : Gauntlet Firewall erlaubt Eindringlingen die Ausführung beliebigen Codes 13: : Wurm nutzt Buffer Overflow in Telnet Daemon aus 14: : iplanet Messaging Server Buffer Overflow 15: : KRB5 TelnetD Buffer Overflows 16: : Remoter Buffer Overflow im HP-UX Line Printer Daemon 17: : Microsoft IIS ssinc.dll Buffer Overflow 18: : Mehrere Sambar Telnet Proxy Schwachstellen 19: : CesarFTP anfällig für Buffer Overflow 20: : Microsoft IIS Patch fehlerhaft 21: : WS_FTP Server Buffer Overflow und möglicher DoS 22: : Windows Media Player.NSC Prozessor enthält ungeprüften Buffer 23: : telnet Daemon Schwachstelle bei mehreren Herstellern 24: : Xvt Buffer Overflow Schwachstelle 25: : CFingerd Sicherheitslücke führt zu Root Compromise 26: :.IDA 'Code Red' Wurm 27: : Solaris ptexec Buffer Overflow 28: : Buffer Overflow im GazTek HTTP Daemon 29: : Oracle 8i Buffer Overflow in TNS Listener 30: : InterScan VirusWall FtpSaveCSP.dll Buffer Overflow 31: : Ungeprüfter Buffer in Index Server ISAPI Extension 32: : Microsoft HyperTerminal Patch revidiert 33: : WFTPD Verzeichnistraversale und Buffer Overflow 34: : Matt's ICQ Clone Sicherheitslöcher 35: : Winamp AIP ausnutzbarer Pufferüberlauf 36: : Remote Kompromittierung von IIS 5.0 Server 37: : Riskante Ntpd & Xntpd Löcher 38: : Multiple AT&T VNC Bugs 39: : Solaris Xsun Buffer Überlauf 40: : Buffer Überlauf in MySQL 41: : Tcpdump remote Root Schwachstelle 42: : BRICKServer DoS 43: : Schon die ActiveX Löcher gepatcht? 44: : Buffer Überlauf in Lotus Domino SMTP Server 45: : Netscape Servers Heap Buffer Overflow 46: : IMAPd Buffer Overflow 47: : AOL Buffer Überlauf 48: : Symantec PCAnywhere Buffer Overflow DoS 50: : MS SQL Server Schwachstelle 51: : Mehrere Schwachstellen in Half-life 52: : Ethereal Data-parsing Buffer Overflow 53: : PowerPoint File-Parsing Buffer Überlauf 54: : Netsnap Webcams remoter Buffer Overflow 55: : DoS in Intel Corporation InBusiness Station 56: : Macromedia Flash SWF Buffer Overflow auf allen Plattformen 57: : Windows HyperTerminal Buffer Overflow Abb. 8: die wichtigsten Buffer-Schwachstellen des letzten Jahres aus:

14 3. Die Buffer-Overflow-Problematik Seite 14 Die Ausmaße des Buffer-Overflow-Problems sind wirklich erschreckend. Auffallend ist das breite Spektrum an Software, welche dieser Schwachstelle unterliegt. Eine Ursache dafür kann die weite Verbreitung der Programmiersprache C sein. Bei meiner Recherche der 57 Attacken des Jahres haben sich folgende Software- Kategorien mit der Buffer-Overflow-Thematik auseinanderzusetzen: Betriebssysteme 19.3% WEB-Server 15.8% Terminal-Programme 12.3% FTP-Server 8.8% Datenbanken 7.0% MAIL -Server 5.3% Game-Server 1.8% sonstige 29.7% Betriebssysteme WEB-Server Terminal-Programme FTP-Server Datenbanken MAIL-Server Game-Server sonstige Abb. 9: Auswertung der Buffer-Schwachstellen nach Software-Kategorie Die Verteilung der Schwachstellen an den Betriebsystemen und an der Software, die für die Betriebsysteme geschrieben wurde, soll die folgende Graphik anhand der beiden großen Betriebsystem-Plattformen illustrieren: MS Windows-Plattformen & Produkte 55.0% UNIX -Plattformen & Produkte 45.0% MS Windows UNIX Abb. 10: Auswertung der Buffer-Schwachstellen nach Betriebsystem-Plattformen

15 3. Die Buffer-Overflow-Problematik Seite Betrachtung der angreifbaren Software Aus der Statistik der registrierten Probleme des letzten Jahres lassen sich noch weitere Schlußfolgerungen ziehen. Generell ist jede Software von Buffer-Overflow- Angriffen bedroht. Es stellt sich jedoch die Frage, bei welcher Software der Angreifer den größten Nutzen bei geringstem Aufwand ziehen kann. Dies ist bei Systemen der Fall, die von außen zugänglich sind. Dort sind in erster Linie die Betriebssysteme zu nennen, deren Vielfalt recht begrenzt ist. Doch dazu mehr im Kapitel Klassisch im Internet sichtbar sind die WEB-Server sowie die Terminal-, FTP- sowie Mail-Dienste. Hinter den WEB-Servern werden zunehmend Datenbanken, wie Oracle (8,29), MySQL (40) und MS-SQL (50) eingesetzt. Auch Game-Server, wie der Half-live Dedicated Server (51), gewinnen an Bedeutung und werden somit auch interessant für Buffer- Overflow-Angriffe. Es ist auch erschreckend, wie einfach manche Overflows erzeugt werden können. Wird an einem Telnet-Server ein überlanger User-Namen eingegeben 14, kann dies den Kaltstart der Station zur Folge haben. Der BRICKHouse Webserver kann bereits durch Angabe einer überlangen URL zum Absturz gebracht werden Vergleich von properitärer und open-source Software Beim Vergleich der properitären Microsoft-Software und deren Produkten mit der open-source Software hätte vor einigen Jahren das sichere Linux mit Abstand gewonnen. Heutzutage ist der Abstand jedoch drastisch gesunken. Ist Windows sicherer geworden oder Linux unsicherer? Ich bin der Meinung, daß Jakub Kaminski von Computer Associates Australia die richtigen Worte gefunden hat, als er sagte, daß die wachsende Popularität von Linux auch Probleme mit sich bringt. Die Anzahl der Linux-Würmer und Viren habe in den letzten 12 Monaten stark zugenommen, ebenso die DDoS-Angriffe 16. Lange Zeit war Windows das Betriebssystem für den Heimanwender, der vom System an sich nichts verstand und es einfach nur benutzen wollte. Linux-User dagegen kannten sich grundsätzlich im Kernel aus und lösten Probleme und Schwachstellen kurzerhand selbst. Diese Zeiten sind jedoch vorbei. Des weiteren ist Linux mit seinen Produkten keine reine Server-Software mehr. Das wachsende Interesse an Linux- Produkten geht in erster Linie von den Heimanwendern und kleinen sowie mittelständischen Unternehmen aus, die durch die unangenehme Lizensierungs-Politik und durch die Arroganz von Microsoft abgeschreckt werden. Um dieses wachsende Interesse zu befriedigen, wurde die Linux-KDE und der Kernel immer einfacher zu handhaben und blähte sich dadurch auf. Außerdem haben Hacker natürlich immer ein großes Interesse an einem großen Software-Spektrum, damit ihre Produkte möglichst großflächig einschlagen. Dadurch wird Linux etwas näher beleuchtet, wodurch natürlich auch die Fehler schneller sichtbar werden. 14 vgl. Kapitel 5.2., Artikel vgl. Kapitel 5.2., Artikel vgl. Kapitel 5.2., Artikel 09

16 3. Die Buffer-Overflow-Problematik Seite 16 Einen unbestreitbaren Vorteil haben open-source Produkte jedoch immer noch. Durch den open-source-gedanken kann prinzipiell jeder kundige Anwender ein Patch selbst programmieren, während man bei Microsoft immer auf das Wohlwollen eines großen Konzerns angewiesen ist. Entscheidet der Konzern, daß der Aufwand für ein Patch aufgrund der mangelnden Wichtigkeit einer Sicherheitslücke zu hoch ist, so wird nie ein Patch erscheinen. Ferner scheint Microsoft ein Problem mit der Verbreitung der überdurchschnittlich großen Zahl an Patches zu haben 17, wobei manche Patches anscheinend selbst noch fehlerhaft sind 18, was das Vertrauen nicht gerade fördert. Ein weiteres Microsoft-Problem ist die zwingende Integration von Komponenten, die streng genommen nicht zum eigentlichen Betriebssystem gehören. Ein Paradebeispiel dafür ist der Microsoft Internet Information Server, bei dem ein Buffer-Overflow unmittelbar den Zugriff auf das Gesamtsystem nach sich ziehen kann. Auch die zunehmende Integration von Medien-Komponenten, wie den Windows Media Player, bringt Probleme mit sich 19. Auch die UNIX-Derivate haben aufgrund ihrer Historie ein Problem, daß sie noch einige Zeit verfolgen wird. UNIX ist wesentlich älter als Windows und wurde ursprünglich für Labor-Umgebungen programmiert. Die remote-kommandos und die Mail-Dienste waren nicht dafür ausgelegt, einem Angriff standzuhalten. Es wurde davon ausgegangen, daß die Benutzer nur sinnvolle Eingaben tätigen. Daher muß UNIX einen Prozeß durchleben, der das System an die harte Realität der heutigen Zeit anpaßt Maßnahmen zur Vermeidung von Buffer-Overflow-Angriffen Bei den Maßnahmen zur Vermeidung von Buffer-Overflow-Angriffen muß man generell zwei Standpunkte unterscheiden, nämlich den des Programmierers und den des Anwenders. Sowohl der Programmierer, als auch der Anwender sollte sich zunächst bewußt machen, daß keine sichere Software existiert! Anwender, dazu zählen insbesondere Administratoren, sollten regelmäßig auf Internet- Seiten wie nach Schwachstellen in der von ihnen eingesetzten Software schauen und sich über die dazugehörigen Patches informieren. Sicherheit ist bekanntlich ein zyklischer Prozeß. Weiterhin sollten sie nach Möglichkeit alle unnötigen Komponenten des Betriebssystems abschalten, besonders diejenigen, welche einen Remote-Zugriff erlauben. Jede installierte Komponente bietet grundsätzlich ein Angriffsziel. Da immer mehr Anwender über ein Intranet und eine DSL-Flatrate verfügen, sollte man sich über die Möglichkeiten von Firewalls informieren, die mittlerweile auch gratis verfügbar sind. Eine neue Technologie wie DSL sollte nie ohne das dafür notwendige neue Wissen verwendet werden. 17 vgl. Kapitel 5.2., Artikel vgl. Kapitel 5.2., Artikel vgl. Kapitel 5.2., Artikel 04 und 22

17 3. Die Buffer-Overflow-Problematik Seite 17 Der Programmierer sollte sich überlegen, welche Programmiersprache er für die Erstellung seiner Software verwendet. Programme in höheren Sprachen können generell weniger Schaden anrichten als Programme, welche direkten Zugriff auf den Speicher des Systems ermöglichen. Jedoch läßt es sich bei hardwarenahen Aufgaben nicht grundsätzlich vermeiden, auch ein hardwarenahes Programmiersystem einzusetzen. In diesem Fall ist unbedingt auf eine saubere Programmierung unter Vermeidung von dynamischen Arrays zu achten, wobei alle Benutzereingaben einen Sicherheitscheck mit Plausibilitätskontrolle, durchlaufen müssen. Dies kann durch die Einhaltung des folgenden Modells geschehen: Anwender Input-Check Anwendung Betriebssystem Abb. 11: Modell zur sicheren Programmierung Der Input der Anwendung, welche auf Resourcen des Betriebssystems zugreift, wird durch ein eigenständiges Modul geprüft. Jede eingehende Kommunikation wird grundsätzlich überprüft und ggf. zurückgewiesen.

18 4. Abschließende Anmerkungen Seite Abschließende Anmerkungen Abschließend betrachtet kann ich natürlich nicht die ultimative Lösung des Buffer- Overflow-Problems liefern, das bereits seit 13 Jahren bekannt und gefürchtet ist. Mein Anliegen war es lediglich, dem Leser einen tieferen Einblick in eine gezielte Schwachstelle der Internet-Sicherheit zu gewähren. Die Existenz dieser Schwachstelle sollte zunächst einmal sowohl vom Programmierer, als auch vom Anwender realisiert werden und im Anschluß daran sollte vermittelt werden, wie ein Hacker diese Schwachstelle ausnutzen kann. Die Brisanz der Buffer-Overflow-Problematik sollte jedem Leser spätestens beim Durchsehen des Anhangs 5.2. bewußt geworden sein. Ich hoffe, daß ich dieses Ziel erreicht habe. Ich muß sagen, daß die Internet-Recherche, das Einarbeiten in die Thematik und das Erstellen dieser Ausarbeitung sehr interessant war und Spaß gemacht hat. Ich hoffe, daß sich dieses Feeling auch auf den Leser dieser Arbeit ein Stück weit überträgt und dazu animiert, sich mit der Thematik näher zu beschäftigen.

19 5. Anhang Seite Anhang shellcode -Beispiel 20 Der Zweck von Shellcode ist es, eine Shell zu starten. Das folgende C Programm macht genau das. /* shellcode1.c */ #include <stdio.h> #include <unistd.h> int main() { char * name[] = {"/bin/sh", NULL}; execve(name[0], name, NULL); return (0); } Es gibt einige Möglichkeiten, eine Shell zu starten, aber viele Gründe sprechen für die Benutzung der Funktion execve(). Erstens is es ein wirklicher Systemcall und keine Funktion aus einer Biblothek, wie viele andere Funktionen der exec() Familie. Ein Systemcall erfolgt aus einem Interrupt. Es ist genug, die Register richtig zu setzen und man kann alles mit einem kurzen und effektiven Stück Assembler erledigen. Außerdem, falls execve() erfolgreich ausgeführt ist, wird die aufrufende Applikation nicht mehr weiter abgearbeitet. Der neue Programmcode ersetzt den Prozess der aufrufenden Applikation. Falls execve() versagt, geht die Programmausführung normal weiter. In unserem Beispiel wird der Code mitten in der attakierten Apllikation eingefügt. Würde die Applikation nach unserem Code weiterlaufen, wäre das völlig bedeutungslos und könnte unter Umständen katastrophal sein. Mit return (0) kann man ein Programm beenden, aber nur wenn es in der Funktion main() benutzt wird. Da unser Programm irgendwo eingefügt werden soll, müssen wir exit() verwenden: /* shellcode2.c */ #include <stdio.h> #include <unistd.h> int main() { char * name [] = {"/bin/sh", NULL}; execve (name [0], name, NULL); exit (0); } Tatsächlich ist exit() wieder eine Funktion aus einer Bibliothek. Der eigentliche Systemcall ist _exit(): /* shellcode3.c */ #include <unistd.h> #include <stdio.h> 20 vgl.:

20 5. Anhang Seite 20 int main() { char * name [] = {"/bin/sh", NULL}; execve (name [0], name, NULL); _exit(0); } Jetzt ist es an der Zeit, das Program mit seinem Assemblercode zu vergleichen. Assembler Wir benutzen gcc und gdb, um den Assemblercode für unser kleines Programm zu erhalten. Wir kompilieren unser shellcode3.c mit der Debugoption (-g) und Linken es statisch (mit -- static), um Bibiotheken mit einzuschließen. Nun haben wir alle Informationen, um herauszufinden, wie _exexve() und _exit() auf Assemblerebene funktionieren. $ gcc -o shellcode3 shellcode3.c -O2 -g --static gdb gibt uns den Assemblercode. Dieser Code ist natürlich nur für eine Plattform (hier Intel i386). $ gdb shellcode3 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Wir bitten gdb, den Assemblercode der Funktion main() aufzulisten: (gdb) disassemble main Dump of assembler code for function main: 0x <main>: push %ebp 0x <main+1>: mov %esp,%ebp 0x804816b <main+3>: sub $0x8,%esp 0x804816e <main+6>: movl $0x0,0xfffffff8(%ebp) 0x <main+13>: movl $0x0,0xfffffffc(%ebp) 0x804817c <main+20>: mov $0x8071ea8,%edx 0x <main+25>: mov %edx,0xfffffff8(%ebp) 0x <main+28>: push $0x0 0x <main+30>: lea 0xfffffff8(%ebp),%eax 0x <main+33>: push %eax 0x804818a <main+34>: push %edx 0x804818b <main+35>: call 0x804d9ac < execve> 0x <main+40>: push $0x0 0x <main+42>: call 0x804d990 <_exit> 0x <main+47>: nop End of assembler dump. (gdb) Die Aufrufe der Funktionen an den Adressen 0x804818b und 0x rufen die Funktionen aus den C Bibliotheken auf, die die eigentlichen Systemaufrufe ausführen. Beachte: 0x804817c : mov $0x8071ea8,%edx füllt das %edx Register mit einem Wert, der wie eine Adresse aussieht. Laß uns einen Blick auf den Speicherinhalt dieser Adresse werfen und sie als String darstellen: