In About Security #9 erfuhren Sie, wie Pufferüberlauf-Schwachstellen im Sourcecode gefunden werden können. Der liegt aber nicht immer vor, Schwachstellen z.B. in Bibliotheken müssen in den fertig kompilierten Binärdateien gesucht werden. In dieser Folge geht es um die Frage, wie Sie Pufferüberlauf-Schwachstellen in Binaries finden können. Dafür 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 und Sharefuzz. 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 oder Spike. 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 Pointers bis zur Änderung von Variablen oder Befehlen. Bekannte Beispiele für Debugger sind der Gnu-Debugger gdb und der 2006 eingestellte Debugger SoftICE.

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. 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, 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'`

Damit wird der Editor mit einem 1024 Zeichen langen Parameter als Name der zu öffnenden Datei aufgerufen. 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-Variablen 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 </home/test/edit> ***
 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 Folge geht es um die Sicherheit von Webanwendungen, zuerst um SQL Injection.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Eine typische Schwachstelle: Der Pufferüberlauf"

• About Security #5: Der Pufferüberlauf
• About Security #6: Ausnutzung von Pufferüberlauf-Schwachstellen
• About Security #7: Gegenwehr – Pufferüberläufe verhindern
• About Security #8: Vorbeugung – Pufferüberläufe verhindern
• About Security #9: Sourcecode Audit – Pufferüberläufe finden
• About Security #10: Software Audit – Schwachstellensuche in Binaries