Software::Kernel
Stack-Überläufe im Linux-Kernel bleiben latente Gefahr
Da der offizielle Linux-Kernel immer noch keine Guard-Pages für Stacks verwendet, kann eine unvorsichtige Programmierung zu Überläufen führen, die sich als Sicherheitslücke verwerten lassen. Jann Horn von Google beschreibt ein solches, gerade behobenes Problem im Detail.
Larry Ewing
Es gibt im Prinzip nichts, was Stack-Überläufe im Linux-Kernel verhindert, außer der Umsicht der Entwickler. Denn bei einer Stack-Größe von vier Seiten (16 KB) auf der x86_64-Architektur würde eine zu tiefe Aufrufhierarchie oder Rekursion schnell zum Überlauf führen. Die Programmierer müssen also immer darauf bedacht sein, solche Fälle zu vermeiden. Anzunehmen, dass das zu 100 Prozent gelingt, wäre naiv.
So hat jüngst Jann Horn vom »Project Zero« bei Google eine neue Sicherheitslücke entdeckt, die einen Überlauf im Dateisystem ecryptfs erzeugt, und einen Exploit entwickelt, mit dem man unter Ausnutzung der Lücke Root-Rechte erlangen kann. ecryptfs ist neben overlayfs eines der wenigen Dateisysteme, die ein anderes Dateisystem als Hintergrundspeicher nutzen. Da den Kernel-Entwicklern bewusst ist, dass sich daraus tiefere Aufrufhierarchien der Funktionen ergeben, ist das Stapeln von solchen Dateisystemen eng begrenzt.
Zum Stacküberlauf führte eine Eigenheit von ecryptfs beim mmap-Aufruf. ecryptfs erlaubt mmap für beliebige Dateien, auch wenn die Originaldatei nicht oer mmap eingebunden werden kann. Dies betrifft beispielsweise Dateien im /proc-Dateisystem wie /proc/$pid/mem, /proc/$pid/cmdline und /proc/$pid/environ. ecryptfs übersetzt Zugriffe auf diese in seiner eigenen Seitenfehlerbehandlung durch Lese-Aufrufe.
Konstruiert man nun mehrere Prozesse, die jeweils die Datei /proc/$pid/environ des vorhergehenden Prozesses über ecryptfs mappen, kann man eine beliebige Stack-Tiefe erreichen, was schnell zum Stack-Überlauf führt. Jann Horn beschreibt den Fehler im Bugtracker von Chromium.
Mit einigem Aufwand lässt sich dieser Überlauf dazu verwenden, um Speicherbereiche, die an den Stack angrenzen, zu überschreiben und letztlich eigenen Code mit Root-Rechten auszuführen. Dies beschreibt Horn ausführlicher im Blog von Project Zero.
Die Korrektur des Problems geschah in zwei Patches. Der erste verhindert, dass mmap in ecryptfs funktioniert, wenn die zugrunde liegende Datei kein mmap unterstützt. Der zweite verhindert vorausschauend, dass /proc als Basis-Dateisystem für ecryptfs oder overlayfs dienen kann. Beide Patches wurden am 10. Juni von Linus Torvalds akzeptiert und werden damit in Linux 4.7 aktiv sein. Ältere Kernel werden wohl die gleichen Korrekturen erhalten.
Der Fall ist Wasser auf die Mühlen all derer, die schon länger mehr proaktive Sicherheitsmaßnahmen im Kernel fordern. Das Grsecurity-Projekt hat bereits zahlreiche solche Maßnahmen entwickelt, unter anderem auch Guard-Pages für die Kernel-Stacks. Doch die Übernahme der Grsecurity-Patches ist zäh, teils auch deshalb, weil einige Änderungen inkompatibel mit der einen oder anderen Anwendung sind oder Geschwindigkeit kosten. Im konkreten Fall von Guard-Pages hat Andy Lutomirski nun einen ersten Patch vorgestellt. Dieser ist nicht ganz ohne Kosten. Er scheint das Erzeugen eines Prozesses durch die zusätzlich zu allokierende Speicherseite für die Guard Page um etwa 15% langsamer zu machen. Ob das relevant ist und ob der Patch übernommen wird, ist noch offen.
){kind=small}
