{"id":100548,"date":"2021-06-20T10:22:54","date_gmt":"2021-06-20T08:22:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-yadre-linux-zatragivayushhaya-setevoj-protokol-can-bcm"},"modified":"2021-06-20T10:22:54","modified_gmt":"2021-06-20T08:22:55","slug":"uyazvimost-v-yadre-linux-zatragivayushhaya-setevoj-protokol-can-bcm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/uyazvimost-v-yadre-linux-zatragivayushhaya-setevoj-protokol-can-bcm","title":{"rendered":"Sicherheitsanf\u00e4lligkeit im Linux-Kernel, die das Netzwerkprotokoll CAN BCM betrifft.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im Linux-Kernel wurde eine Schwachstelle (CVE-2021-3609) entdeckt, die es einem lokalen Benutzer erm\u00f6glicht, seine Privilegien im System zu erh\u00f6hen. Das Problem wird durch einen Race-Condition in der Implementierung des CAN BCM-Protokolls verursacht und tritt in den Kernel-Versionen von 2.6.25 bis 5.13-rc6 auf. In den Distributionen bleibt das Problem bisher ungel\u00f6st (RHEL, Fedora, Debian, Ubuntu, SUSE, Arch). <\/p>\n
Der Entdecker der Schwachstelle konnte einen Exploit vorbereiten, um Root-Rechte auf Systemen mit Linux-Kernels 5.4 und neuer zu erlangen, wobei auch die erfolgreiche Durchf\u00fchrung eines Angriffs in Ubuntu 20.04.02 LTS gezeigt wurde. Es besteht nicht ausgeschlossen, dass der Exploit auch f\u00fcr die Arbeit mit \u00e4lteren Kernen \u00fcberarbeitet wird (im Kernel 5.4 wurde der Code f\u00fcr CAN BCM (net\/can\/bcm.c) von hrtimer_tasklet auf HRTIMER_MODE_SOFT umgestellt). <\/p>\n
Das CAN BCM-Protokoll erm\u00f6glicht es, einen eigenen Nachrichten-Handler zu registrieren, der \u00fcber den CAN-Bus (Controller Area Network) Nachrichten empf\u00e4ngt, und an einen bestimmten Netzwerk-Socket anzuh\u00e4ngen. Bei Eingang einer Nachricht wird die Funktion bcm_rx_handler() aufgerufen. Der Angreifer kann den Race-Condition nutzen und den Netzwerk-Socket gleichzeitig mit der Ausf\u00fchrung von bcm_rx_handler() schlie\u00dfen. Beim Schlie\u00dfen des Sockets wird die Funktion bcm_release() aufgerufen, in der der Speicher, der f\u00fcr die Strukturen bcm_op und bcm_sock reserviert wurde, freigegeben wird, obwohl diese weiterhin im laufenden Handler bcm_rx_handler() verwendet werden. Dies f\u00fchrt zu einem Zugriff auf einen bereits freigegebenen Speicherblock (Use-After-Free). <\/p>\n
Der Angriff besteht darin, zwei CAN BCM-Sockets zu \u00f6ffnen und sie an das Interface vcan zu binden. Im ersten Socket wird sendmsg() mit dem RX_SETUP-Flag aufgerufen, um den Handler f\u00fcr eingehende CAN-Nachrichten zu konfigurieren, w\u00e4hrend im zweiten Socket ein sendmsg()-Aufruf gemacht wird, um eine Nachricht an den ersten Socket zu senden. Nach dem Eintreffen der Nachricht wird bcm_rx_handler() aufgerufen, und der Angreifer w\u00e4hlt den richtigen Moment, um den ersten Socket zu schlie\u00dfen, was die Ausf\u00fchrung von bcm_release() und die Freigabe der Strukturen bcm_op und bcm_sock ausl\u00f6st, obwohl die Arbeit von bcm_rx_handler() noch nicht abgeschlossen ist. <\/p>\n
Durch Manipulation des Inhalts von bcm_sock kann ein Angreifer den Zeiger auf die Funktion sk->sk_data_ready(sk) umdefinieren, die Ausf\u00fchrung umleiten und durch Techniken der R\u00fccksprungorientierten Programmierung (ROP \u2014 Return-Oriented Programming) den Parameter modprobe_path \u00fcberschreiben, um seinen Code mit Root-Rechten auszuf\u00fchren. Bei der Verwendung der ROP-Technik versucht der Angreifer nicht, seinen eigenen Code im Speicher abzulegen, sondern arbeitet mit bereits vorhandenen Maschinencode-St\u00fccken aus geladenen Bibliotheken, die mit einer R\u00fcckgabebefehl enden (in der Regel sind dies die Abschl\u00fcsse von Bibliotheksfunktionen). Die Funktionsweise des Exploits besteht darin, eine Kette von Aufrufen solcher Bl\u00f6cke (\"Gadgets\") zum Erreichen der gew\u00fcnschten Funktionalit\u00e4t zu konstruieren.
<\/center> <\/p>\n
F\u00fcr den Angriff ist der Zugriff zur Erstellung von CAN-Sockets und eine konfigurierte Netzwerkschnittstelle vcan erforderlich. Die f\u00fcr den Angriff erforderlichen Berechtigungen k\u00f6nnen von einem nicht privilegierten Benutzer in Containern erlangt werden, die in Systemen mit aktivierter Unterst\u00fctzung f\u00fcr Benutzer-Namensr\u00e4ume (user namespaces) erstellt werden. Beispielsweise sind Benutzer-Namensr\u00e4ume standardm\u00e4\u00dfig in Ubuntu und Fedora aktiviert, aber nicht in Debian und RHEL. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Sicherheitsanf\u00e4lligkeit](\"\/wp-content\/uploads\/2021\/06\/60534f0194a819c8401abf2ec53b3a9a.png\")
<\/center> <\/p>\n