Dienstag, 15. Juni 2010


Topthema

Donnerstag, 16. Juni 2005 | Topthema

About Security #10: Software- Audit — Schwachstellensuche in Binaries

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/022272)

About Security #10: Software-Audit — Schwachstellensuche in Binaries

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.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

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
About Security: Die komplette Serie

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.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "Eine typische Schwachstelle: Der Puffer�berlauf"

Kommentare

Folgende Links könnten Sie auch interessieren