Forscher des Google Project Zero-Teams veröffentlichten eine Methode zur Ausnutzung einer Schwachstelle (CVE-2020-29661) in der Implementierung des ioctl-Handlers TIOCSPGRP aus dem tty-Subsystem des Linux-Kernels und beleuchteten ausführlich die Schutzmechanismen, die solche Schwachstellen blockieren könnten.
Der problematische Fehler wurde im Linux-Kernel bereits am 3. Dezember letzten Jahres behoben. Das Problem tritt in Kerneln bis zur Version 5.9.13 auf, aber die meisten Distributionen haben das Problem in Paketupdates mit Kerneln, die bereits im letzten Jahr angeboten wurden, behoben (Debian, RHEL, SUSE, Ubuntu, Fedora, Arch). Eine ähnliche Schwachstelle (CVE-2020-29660) wurde gleichzeitig in der Implementierung des ioctl-Aufrufs TIOCGSID gefunden, aber auch diese wurde bereits weitgehend behoben.
Das Problem wird durch einen Fehler bei der Einrichtung von Sperren verursacht, der zu einem Race Condition im Code drivers/tty/tty_jobctrl.c führt, der ausgenutzt werden konnte, um Bedingungen für den Zugriff auf Speicher nach dessen Freigabe (use-after-free) zu schaffen, die aus dem Benutzerspeicher durch Manipulation mit dem ioctl-Aufruf TIOCSPGRP ausgenutzt werden konnten. Ein funktionierender Exploit wurde zur Erhöhung der Berechtigungen in Debian 10 mit dem Kernel 4.19.0-13-amd64 demonstriert.
In dem veröffentlichten Artikel wird jedoch der Fokus nicht so sehr auf der Technik zur Erstellung eines funktionierenden Exploits gelegt, sondern darauf, welche Werkzeuge im Kernel existieren, um solche Schwachstellen zu schützen. Die Schlussfolgerung ist wenig beruhigend: Methoden wie die Segmentierung von Speicher im Heap und die Kontrolle des Zugriffs auf den Speicher nach dessen Freigabe kommen in der Praxis nicht zur Anwendung, da sie die Leistung beeinträchtigen, und der auf CFI (Control Flow Integrity) basierende Schutz, der Exploits in späteren Phasen eines Angriffs blockiert, einer Überarbeitung bedarf.
In Bezug auf die Überlegung, was die Situation langfristig verbessern könnte, wird die Anwendung fortschrittlicher statischer Analysatoren oder die Verwendung von Programmiersprachen, die sicheren Umgang mit Speicher ermöglichen, wie Rust und Dialekte der Programmiersprache C mit erweiterten Annotationen (z. B. Checked C), in Betracht gezogen, um während des Build-Prozesses den Zustand von Sperren, Objekten und Zeigern zu überprüfen. Unter den Schutzmaßnahmen wird auch die Aktivierung des Modus panic_on_oops, der Übergang von Kernelstrukturen in einen Nur-Lese-Modus und die Beschränkung des Zugriffs auf Systemaufrufe durch Mechanismen wie seccomp erwähnt.
Quelle: opennet.ru
