Linux: Vom einfachen Speicherfehler zur Systemübernahme

Der Google-Entwickler Jann Horn beschreibt in einem langem Blogpost für Googles Project Zero detailliert die Ausnutzung einer Lücke im Linux-Kernel. Bei dem eigentlichen Fehler handelt es sich um eine sogenannte Use-After-Free-Lücke, die "relativ normal" sei und zum Beispiel bei C-Code zu den typischen Fehlern gehört.

Horn gelang es, auf Grundlage des Fehlers vollen Systemzugriff zu erlangen. Er schreibt dazu: "Ich hoffe, dass das Durchlaufen eines solchen Exploits und die Weitergabe dieses gesammelten Wissens an die breitere Sicherheitsgemeinschaft dazu beitragen kann, den relativen Nutzen verschiedener Gegenmaßnahmen zu erörtern."

Zu der sehr ausführlichen und mit expliziten Code-Beispielen versehenen Beschreibung zum Ausnutzen der Lücke schreibt Horn darüber hinaus: "Es handelte sich im Wesentlichen um einen langweiligen Locking-Fehler in einem zufälligen Kernel-Subsystem, der, wenn es sich nicht um einen Speicherfehler handeln würde, eigentlich keine große Bedeutung für die Systemsicherheit haben sollte. Ich habe einen ziemlich einfachen, unaufregenden (und zugegebenermaßen unzuverlässigen) Exploit für diesen Fehler geschrieben; und die wahrscheinlich größte Herausforderung, auf die ich bei dem Versuch, ihn unter Debian auszunutzen, gestoßen bin, war, richtig zu verstehen, wie der SLUB-Allokator funktioniert."

Compiler-Werkzeuge nicht ausreichend

Der Sicherheitsforscher beschreibt damit ein inzwischen typisches Bild für die Einordnung von C-Code und damit verbundenen Speicherfehlern, die von vielen in der IT-Industrie vermehrt als sehr großes Sicherheitsproblem gesehen werden. Doch Horn führt aus, dass etwa die inzwischen für Compiler wie Clang umgesetzten Werkzeuge mit rein praktischen Schwierigkeiten konfrontiert seien.

Für die Thread-Analyse brauche es etwa Annotationen, die von der Community betreut werden müssten. Eine globale statische Analyse finde außerdem nur einen Teilmenge bestimmter Fehler und sei möglicherweise nicht geeignet, die Korrektheit von sicheren Speicherzugriffen zu beweisen. Auch Techniken wie Control-Flow Integrity hätten auf den von Horn entwickelten Exploit keinerlei Auswirkung, da dieser komplett auf einer Datenmanipulation basiert, nicht auf der Manipulation von Zeigern oder Ähnlichem.

Horn schreibt außerdem, dass die aktuelle Situation der Software-Sicherheit "dramatisch verbessert" werden könne. Kurzfristig seien hier jedoch nur einige Notlösungen denkbar. "Langfristig denke ich, muss sich an der Programmiersprache etwas ändern - schlichtes C ist einfach zu fehleranfällig." Ob das inzwischen oft als C-Ersatz gepriesene Rust die richtige Antwort ist, kann Horn aber auch nicht sagen.