Forscher des Google Project Zero-Teams haben eine Ausnutzungsmethode für die Schwachstelle (CVE-2020-29661) in der Implementierung des ioctl-Handlers TIOCSPGRP aus dem tty-Subsystem des Linux-Kernels veröffentlicht und die Schutzmechanismen detailliert untersucht, 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 bereits in den Kernel-Paket-Updates behoben, die im vergangenen Jahr bereitgestellt wurden (Debian, RHEL, SUSE, Ubuntu, Fedora, Arch). Eine ähnliche Schwachstelle (CVE-2020-29660) wurde gleichzeitig in der Implementierung des ioctl-Aufrufs TIOCGSID gefunden, wurde jedoch ebenfalls bereits umfassend behoben.
Das Problem wurde durch einen Fehler bei der Sperrsetzung verursacht, der zu einem Race Condition im Code drivers/tty/tty_jobctrl.c führte, der ausgenutzt werden konnte, um Bedingungen für einen Zugriff auf den Speicher nach dessen Freigabe (use-after-free) zu schaffen, die aus dem Benutzerspeicher durch Manipulation des ioctl-Aufrufs TIOCSPGRP ausgenutzt werden konnten. Ein funktionierender Exploit für die Erhöhung von Berechtigungen wurde für Debian 10 mit dem Kernel 4.19.0-13-amd64 demonstriert.
Der veröffentlichte Artikel legt den Schwerpunkt nicht so sehr auf die Technik zur Erstellung eines funktionierenden Exploits, sondern darauf, welche Werkzeuge im Kernel vorhanden sind, um sich vor solchen Schwachstellen zu schützen. Die Schlussfolgerung ist wenig tröstlich: Methoden wie die Segmentierung von Speicher in der Heap und die Überwachung des Zugriffs auf den Speicher nach dessen Freigabe kommen in der Praxis nicht zum Einsatz, da sie die Leistung beeinträchtigen. Der auf CFI (Control Flow Integrity) basierende Schutz, der Exploits in späteren Angriffsphasen blockiert, bedarf weiterer Entwicklungsarbeiten.
Bei der Überlegung, was die Situation langfristig verbessern könnte, wird die Anwendung fortschrittlicher statischer Analysewerkzeuge hervorgehoben oder die Nutzung von Programmiersprachen, die eine sichere Speicherverwaltung bieten, wie Rust und Dialekte von C mit erweiterten Annotationen (z. B. Checked C). Diese sollten in der Phase der Kompilierung den Zustand von Sperren, Objekten und Zeigern überprüfen. Zu den Schutzmaßnahmen zählt auch die Aktivierung des Modus panic_on_oops, die Umstellung von Kernelstrukturen auf einen Nur-Lese-Modus und die Einschränkung des Zugriffs auf Systemaufrufe durch Mechanismen wie seccomp.
Quelle: opennet.ru
