Glibc: Fehlerhaftes Null-Byte führt zu Root-Zugriff

Mitgliedern von Googles Project Zero ist es gelungen, einen kleinen Fehler in der Glibc auszunutzen, um unter einem Linux-System Root-Zugriff zu erhalten. Dafür mussten zahlreiche Hürden überwunden werden.

Artikel veröffentlicht am 26. August 2014, 11:25 Uhr, Hanno Böck

Ein Fehler in der Glibc-Bibliothek überschreibt ein einzelnes Byte an der falschen Stelle. (Bild: Screenshot)

Googles Project Zero hat einen Exploit entwickelt, mit dem man durch einen Fehler in der Glibc-Bibliothek unter manchen Linux-Systemen Root-Zugriff erhalten kann. Den Fehler hatte Google-Entwickler Tavis Ormandy bereits Mitte Juli öffentlich gemacht, doch bislang wurde er nicht behoben. Der Fehler schlummert wohl schon lange im Glibc-Code: Bereits 2005 wies ein Eintrag in der entsprechenden Mailingliste auf das Problem hin, damals erkannte aber offenbar niemand, dass es sich um ein Sicherheitsproblem handelt.

Bei dem Fehler in der Glibc handelt es sich um einen Buffer Overflow in der internen Funktion __gconv_translit_find(), der ein einziges Null-Byte außerhalb des zulässigen Speicherbereiches schreibt. Dem Problem wurde die ID CVE-2014-5119 zugewiesen. Zunächst hatte es Diskussionen darüber gegeben, ob sich das Problem tatsächlich ausnutzen lässt. Chris Evans und Tavis Ormandy von Googles Project Zero haben daraufhin versucht, genau das zu beweisen, was ihnen letztendlich auch gelungen ist.

Um den Bug auszunutzen, mussten die Entwickler eine ganze Reihe von Hürden überwinden. Moderne Betriebssysteme haben verschiedene Mechanismen, die das Ausnutzen von Buffer Overflows erschweren. Für den Exploit wurde die Fedora-Distribution in der 32-Bit-Version genutzt.

Der Exploit nutzt den Befehl pkexec, der Teil des Policykit-Pakets ist. Die Datei hat das Setuid-Root-Flag, was bedeutet, dass der Befehl immer mit Root-Rechten ausgeführt wird, auch wenn es von einem Nutzer aufgerufen wird. Gelingt es, bei einem solchen Programm eigenen Code auszuführen, kann man Root-Rechte erlangen.

Moderne Betriebssysteme nutzen praktisch alle ALSR (Adress Space Layout Randomization), um Daten im virtuellen Speicher an zufälligen Stellen zu platzieren. Dadurch wird das Entwickeln von funktionierenden Exploits deutlich erschwert. Mit Hilfe des Befehls ulimit lässt sich ein Großteil der Randomisierungen des Speichers umgehen. Anschließend ist nur noch der Stack-Speicher randomisiert, der Heap und die Bibliotheken sind an festen, dem Angreifer bekannten Stellen im Speicher. Dass ein Angreifer mittels ulimit die Randomisierung einer Setuid-Datei beeinflussen kann, ist laut den Google-Entwicklern ein generelles Problem, das behoben werden sollte.

Neben dem Fehler in der Glibc nutzt der Exploit weiterhin ein Memory Leak in pkexec, um den eigentlichen Exploit-Code im Arbeitsspeicher zu platzieren. Daraus schließen Ormandy und Evans, dass generell Speicherlecks in Programmen mit dem Setuid-Root-Flag überraschend gefährlich sind.

Letztlich wollten die Entwickler von Project Zero mit dieser Demonstration zeigen, dass selbst Bugs, die auf den ersten Blick harmlos erscheinen, sich mit viel Aufwand ausnutzen lassen. Diskussionen darüber, ob ein Fehler tatsächlich für einen Angreifer ausnutzbar ist, würden oft Zeit und Energie kosten, die man besser in das Beheben der Fehler stecken sollte. Der Exploit in seiner jetzigen Form funktioniert nur unter 32-Bit-Systemen und nutzt auch einige Besonderheiten von Fedora. Evans schreibt, dass es gut möglich sei, dass der Bug sich mit anderen Methoden auch unter 64-Bit-Systemen ausnutzen lasse.

Mit Project Zero versucht Google, generell die Sicherheit der IT-Infrastruktur zu verbessern. Google hat hierfür einige Sicherheitsspezialisten engagiert, die ausschließlich mit der Suche nach sicherheitskritischen Bugs in Softwareprodukten aller Art beschäftigt sind. Zuletzt wurden von Project Zero Sicherheitsprobleme im Flash-Browserplugin, in Safari und in Mac OS X entdeckt und veröffentlicht.