Im Kern Linux Es wurde eine Sicherheitslücke (CVE-2021-3609) identifiziert, die es einem lokalen Benutzer ermöglicht, seine Systemrechte zu erweitern. Das Problem wird durch eine Race Condition in der CAN-BCM-Protokollimplementierung verursacht und ist in allen Kernel-Versionen vorhanden. Linux von Version 2.6.25 bis 5.13-rc6. Das Problem besteht in den Distributionen (RHEL, Fedora, Debian, Ubuntu, SUSE, Arch).
Der Forscher, der die Sicherheitslücke entdeckte, konnte einen Exploit vorbereiten, um Root-Rechte auf Systemen mit folgenden Kerneln zu erlangen: Linux 5.4 und später, einschließlich der Möglichkeit, einen Angriff erfolgreich durchzuführen in Ubuntu 20. April 2002 LTS. Es ist möglich, dass der Exploit so überarbeitet werden kann, dass er auch mit älteren Kerneln funktioniert (im Kernel 5.4 wurde der CAN BCM-Code (net/can/bcm.c) von hrtimer_tasklet nach HRTIMER_MODE_SOFT verschoben).
Mit dem CAN-BCM-Protokoll können Sie Ihren eigenen Nachrichtenhandler, der über den CAN-Bus (Controller Area Network) ankommt, registrieren und an einen bestimmten Netzwerk-Socket anschließen. Wenn eine eingehende Nachricht eintrifft, wird die Funktion bcm_rx_handler() aufgerufen. Ein Angreifer kann eine Race-Bedingung ausnutzen und bewirken, dass der Netzwerk-Socket gleichzeitig mit der Ausführung von bcm_rx_handler() geschlossen wird. Wenn der Socket geschlossen wird, wird die Funktion bcm_release() aufgerufen, die den für die Strukturen bcm_op und bcm_sock zugewiesenen Speicher freigibt, der weiterhin im noch ausgeführten Handler bcm_rx_handler() verwendet wird. Es entsteht eine Situation, die zum Zugriff auf einen bereits freigegebenen Speicherblock führt (Use-after-free).
Der Angriff läuft darauf hinaus, zwei CAN-BCM-Sockets zu öffnen und sie an die VCAN-Schnittstelle zu binden. Der erste Socket ruft sendmsg() mit dem RX_SETUP-Flag auf, um einen Handler für eingehende CAN-Nachrichten einzurichten, und der zweite Socket ruft sendmsg() auf, um eine Nachricht an den ersten Socket zu senden. Nachdem die Nachricht eintrifft, wird der Aufruf von bcm_rx_handler() ausgelöst, und der Angreifer wählt den richtigen Moment und schließt den ersten Socket, was zum Start von bcm_release() und der Freigabe der Strukturen bcm_op und bcm_sock führt, obwohl die Arbeit von bcm_rx_handler erfolgt () ist noch nicht abgeschlossen.
Durch Manipulation des Inhalts von bcm_sock kann ein Angreifer den Zeiger auf die Funktion sk->sk_data_ready(sk) neu definieren, die Ausführung umleiten und mithilfe von ROP-Techniken (Return-Oriented Programming) das Überschreiben des Parameters modprobe_path organisieren und sicherstellen, dass ihr Code wird mit Root-Rechten ausgeführt. Bei Verwendung der ROP-Technik versucht der Angreifer nicht, seinen Code im Speicher abzulegen, sondern arbeitet mit Teilen von Maschinenanweisungen, die bereits in geladenen Bibliotheken verfügbar sind, und endet mit einer Steuerrückgabeanweisung (in der Regel sind dies die Enden von Bibliotheksfunktionen). . Die Arbeit des Exploits besteht darin, eine Kette von Aufrufen ähnlicher Blöcke („Gadgets“) aufzubauen, um die gewünschte Funktionalität zu erhalten.
Der Angriff erfordert Zugriff zum Erstellen von CAN-Sockets und eine konfigurierte vCAN-Netzwerkschnittstelle. Die notwendigen Berechtigungen können von einem Benutzer ohne Administratorrechte in Containern erlangt werden, die auf Systemen mit aktivierten Benutzer-Namespaces erstellt wurden. Beispielsweise sind Benutzer-Namespaces standardmäßig aktiviert in Ubuntu und Fedora, aber nicht aktiviert in Debian und RHEL.
Source: opennet.ru
