Open Source im professionellen Einsatz

glibc: DNS Remote Exploit Im DNS-Code

Im Code zur Unterstützung des Domain Name System der glibc-Bibliothek wurde eine schwerwiegende Sicherheitslücke entdeckt, die es einem entfernten Angreifer erlaubt Befehle mit den Rechten der Applikation auszuführen. Entdeckt wurde das Problem von einem Google Mitarbeiter, der bei seinen SSH-Programmtests immer wieder Segmentation Faults fand. Es stellte sich heraus, dass der Absturz nicht durch einen Fehler in dem getesteten SSH-Client hervorgerufen wurde, sondern durch ein Problem in der glibc-Bibliothek selbst.

In der glibc-Bibliothek ist unter anderem die »getaddrinfo(«)-Funktion für das Verarbeiten von DNS-Paketen zuständig. Der Angreifer muss in der Lage sein spezielle DNS-Informationen an diese Funktion zu senden. Dies geht prinzipiell auf drei Arten: durch spezielle Domain-Namen, durch einen vom Angreifer kontrollierten DNS-Server, oder durch Man-in-the-Middle-Attacken, wo der Angreifer den Datenstrom zur »getaddrinfo()«-Funktion abfängt und modifiziert, um die Schwachstelle auszunutzen.

Der Programmierfehler selbst tritt bei UDP- und TCP-Antworten auf, die mehr als 2048 Bytes lang sind. Internet alloziert der glibc-Code zunächst 2048 Bytes, um DNS-Antworten zu verarbeiten. Die »send_dg()«- (UDP) und »send_vc()«-Funktionen (TCP) verarbeiten dann im Folgenden die DNS-Daten. Sollte es dabei dazu kommen, dass die DNS-Antwort mehr als 2048 Bytes enthält, so sorgen diese Funktionen auch dafür, dass ein neuer Puffer auf dem Heap alloziert wird, der die entsprechende Größe hat. In diesem Moment updaten die Funktionen auch den Zeiger auf den Puffer, dessen Längenangabe und die Antwortgröße. An dieser Stelle kann es nun zu einem Problem kommen. Denn unter bestimmten Umständen kann es passieren, dass der Code den neuen, größeren Heap-Speicher mit dem alten, kleineren Stack-Speicher verwechselt. Der Code wird dann trotz der zu großen DNS-Antwort weiter in den anfänglich allozierten Stack-Speicher schreiben, der allerdings nur 2048 Bytes fasst. Diese Situation führt dann zu einem typische Buffer Overflow auf dem Stack.

Diese Ausgangssituation ist für eine Attacke eigentlich sehr günstig, allerdings führt Address Space Layout Randomization (ASLR) dazu, dass die Entwicklung eines konkreten Exploits nicht ganz trivial ist. Die ASLR-Technik besteht darin den Programmen Adressbereiche zufällig zuzuweisen. Typische Buffer Overflow Exploits benötigen allerdings meist eine klare Speicherstruktur, um effiziente Angriffe zu ermöglichen. Mit ASLR ist das nicht mehr ganz so einfach möglich. Trotzdem gelang es einen funktionierenden Exploit zu entwickeln, der als Proof-of-Concept auf GitHub zur Verfügung steht. Hier wird demonstriert wie durch die Schwachstelle gezielt die Instruction Pointer Register modifiziert werden können, womit sich der Programmablauf kontrollieren lässt. Damit ist dann auch das Ausführen beliebiger Befehle seitens des Angreifers möglich. Ein Patch wurde kürzlich veröffentlicht. Dieser erstreckt sich über einige Funktionen und Dateien des Glibc-DNS-Codes.

comments powered by Disqus

Ausgabe 10/2016

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.