{"id":101712,"date":"2021-10-21T10:22:53","date_gmt":"2021-10-21T08:22:53","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/raskryta-tehnika-ekspluataczii-uyazvimosti-v-tty-podsisteme-yadra-linux"},"modified":"2021-10-21T10:22:53","modified_gmt":"2021-10-21T08:22:53","slug":"raskryta-tehnika-ekspluataczii-uyazvimosti-v-tty-podsisteme-yadra-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/raskryta-tehnika-ekspluataczii-uyazvimosti-v-tty-podsisteme-yadra-linux","title":{"rendered":"Technik zur Ausnutzung einer Schwachstelle im tty-Subsystem des Linux-Kernels aufgedeckt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Forscher des Google Project Zero-Teams ver\u00f6ffentlichten 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\u00fchrlich die Schutzmechanismen, die solche Schwachstellen blockieren k\u00f6nnten. <\/p>\n
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 \u00e4hnliche Schwachstelle (CVE-2020-29660) wurde gleichzeitig in der Implementierung des ioctl-Aufrufs TIOCGSID gefunden, aber auch diese wurde bereits weitgehend behoben. <\/p>\n
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\u00fchrt, der ausgenutzt werden konnte, um Bedingungen f\u00fcr 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\u00f6hung der Berechtigungen in Debian 10 mit dem Kernel 4.19.0-13-amd64 demonstriert. <\/p>\n
In dem ver\u00f6ffentlichten 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\u00fctzen. 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\u00e4chtigen, und der auf CFI (Control Flow Integrity) basierende Schutz, der Exploits in sp\u00e4teren Phasen eines Angriffs blockiert, einer \u00dcberarbeitung bedarf. <\/p>\n
In Bezug auf die \u00dcberlegung, was die Situation langfristig verbessern k\u00f6nnte, wird die Anwendung fortschrittlicher statischer Analysatoren oder die Verwendung von Programmiersprachen, die sicheren Umgang mit Speicher erm\u00f6glichen, wie Rust und Dialekte der Programmiersprache C mit erweiterten Annotationen (z. B. Checked C), in Betracht gezogen, um w\u00e4hrend des Build-Prozesses den Zustand von Sperren, Objekten und Zeigern zu \u00fcberpr\u00fcfen. Unter den Schutzma\u00dfnahmen wird auch die Aktivierung des Modus panic_on_oops, der \u00dcbergang von Kernelstrukturen in einen Nur-Lese-Modus und die Beschr\u00e4nkung des Zugriffs auf Systemaufrufe durch Mechanismen wie seccomp erw\u00e4hnt. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"