Wie letzte Woche angekündigt, geht es heute um die Frage, wie Pufferüberlauf-Schwachstellen in Binaries gefunden werden können. Für die Schwachstellensuche in Binaries gibt es drei Lösungsansätze: Die Fault Injection, die dynamische Analyse und das Reverse Engineering.
Fault Injection
Bei der Fault Injection wird das zu untersuchende Programm mit überlangen oder ungewöhnlichen Parametern aufgerufen bzw. Environment-Variablen auf entsprechende Werte gesetzt. Enthält das Programm eine Pufferüberlauf-Schwachstelle, wird es eine unerwartete Reaktion auf die Eingabe geben, meist einen Absturz. Läuft das Programm normal weiter, enthält es entweder keine durch den entsprechenden Parameter ausnutzbare Pufferüberlauf-Schwachstelle oder der übergebene Parameter war noch nicht groß genug.
Zum einen kann das Programm manuell mit entsprechenden Parametern aufgerufen werden, zum anderen gibt es spezielle Testprogramme dafür. Dabei unterscheidet man zwischen hostbasierten und netzwerkbasierten Programmen.
Hostbasierte Programme sind z.B. BFBTester [1] und Sharefuzz [2]. BFBTester (Brute Force Binary Tester) kann einzelne und mehrere Parameter oder Environment-Variablen entsprechend manipulieren. Sharefuzz dient ausschließlich der Suche nach Pufferüberlauf-Schwachstellen bei der Verarbeitung von Environment-Variablen.
Netzwerkbasierte Programme sind z.B. Hailstorm [3] oder Spike [4]. Hailstorm dient der Suche nach Schwachstellen in Webanwendungen. Außer nach Pufferüberlauf-Schwachstellen kann das Programm auch nach Cross-Site-Scripting- und SQL-Injection-Schwachstellen suchen. Spike dient der Untersuchung von Netzwerkprotokollen und der damit verbundenen Programme.
Dynamische Analyse
Bei der dynamischen Analyse, d.h. der Analyse während der Laufzeit, werden zwei Sorten von Programmen eingesetzt: Tracer und Debugger.
Ein Tracer protokolliert den Ablauf eines Programms. Das erstellte Protokoll wird danach auf verdächtige Vorfälle wie z.B. ungeprüfte Puffer untersucht. Es ist auch möglich, die Verwendung von Variablen nachzuvollziehen und diese dann später gezielt mittels Fault Injection zu testen.
Ein Debugger kann nicht nur wie ein Tracer den Ablauf protokollieren, sondern ihn auch manipulieren. Die möglichen Manipulationen reichen vom Verschieben des Instruction Pointer bis zur Änderung von Variablen oder Befehlen. Beispiele für Debugger sind der Gnu-Debugger gdb [5] und SoftICE [6].
Reverse-Engineering
Beim Reverse-Engineering wird zu einem vorhandenen Programm der Sourcecode entwickelt. Dazu wird das Programm disassembliert oder dekompiliert. Ein dazu häufig verwendetes Programm ist der interaktive Dissassembler IDA-Pro [7]. Interaktiv bedeutet in diesem Zusammenhang, dass der Entwickler während des Dissassemblierens selbst entscheidet, ob Daten als Daten oder Code interpretiert werden sollen. Als Ergebnis erhält man den Sourcecode des Binary in Assembler. Darin kann dann, wie beim Sourcecode-Audit beschrieben, nach verdächtigen Funktionsaufrufen gesucht werden. BugScam [8], eine Erweiterung für IDA-Pro, hilft dabei.
Ein Beispiel
Ein nur binär vorliegendes Programm soll auf Pufferüberlauf-Schwachstellen untersucht werden. Dabei könnte es sich z.B. um einen Editor handeln, der über die Kommandozeile mit dem Namen der zu öffnenden Datei aufgerufen wird. Zuerst kann man versuchen, mittels Fault Injection eine ungewöhnliche Reaktion hervorzurufen:
tester$ edit `perl -e 'print "A"x1024'`
Kommt es zu einem Pufferüberlauf, wird höchstwahrscheinlich ein Segmentation fault gemeldet. Vielleicht reicht einem das Ergebnis schon, vielleicht möchte man aber auch mehr wissen. Wenn schon ein überlanger Dateiname zu einem Pufferüberlauf führt, gibt es vielleicht noch mehr derartige Schwachstellen. In diesem Fall könnte z.B. eine nähere Untersuchung der Environment-Variable interessant sein. Aber auch weitere Kommandozeilenparameter sind lohnende Testobjekte. Um sich die Suche zu erleichtern, kann man nun z.B. BFBTester verwenden:
tester bfbtester -a edit
*** Crash ***
args: -h [05120]
envs:
Signal: 11 ( Segmentation fault )
Core? Yes
Das Programm ist beim Aufruf mit der Option -h und einem 5.120 Zeichen langen Parameter mit einem Segmentierungsfehler abgestürzt. Möchte man noch mehr wissen, kann man mit einem Debugger den Programmablauf näher untersuchen. Dabei interessiert dann meist die Frage, ob es sich um eine reine Denial-of-Service-Schwachstelle handelt oder ob die Ausführung eingeschleusten Codes möglich ist. Notwendig hierfür ist das Überschreiben für den Programmablauf wichtiger Variablen.
Damit ist das Thema "Pufferüberläufe" vorerst abgeschlossen. Ab der nächsten Woche geht es um die Sicherheit von Webanwendungen, zuerst um SQL-Injection.
Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder als Kommentar an die Kolumne anfügen.
