Une vulnérabilité a été détectée dans le noyau Linux (CVE-2021-3609), permettant à un utilisateur local d'élever ses privilèges dans le système. Ce problème est causé par une condition de course dans l'implémentation du protocole CAN BCM et se manifeste dans les versions du noyau Linux de 2.6.25 à 5.13-rc6. Dans les distributions, le problème demeure non corrigé (RHEL, Fedora, Debian, Ubuntu, SUSE, Arch).
Le chercheur ayant découvert la vulnérabilité a réussi à préparer un exploit pour obtenir des droits root sur les systèmes avec des noyaux Linux 5.4 et plus récents, y compris une démonstration de la possibilité d'exécuter une attaque sur Ubuntu 20.04.02 LTS. Il n'est pas exclu que l'exploit puisse être adapté pour fonctionner avec des noyaux plus anciens (dans le noyau 5.4, le code CAN BCM (net/can/bcm.c) a été converti de hrtimer_tasklet à HRTIMER_MODE_SOFT).
Le protocole CAN BCM permet d'enregistrer un gestionnaire de messages personnalisé pour les messages entrant via le bus CAN (controller area network) et de l'attacher à un socket réseau spécifique. Lorsqu'un message entrant arrive, la fonction bcm_rx_handler() est appelée. L'attaquant peut tirer parti de la condition de course et provoquer la fermeture du socket réseau en même temps que l'exécution de bcm_rx_handler(). Lors de la fermeture du socket, la fonction bcm_release() est appelée, libérant la mémoire allouée pour les structures bcm_op et bcm_sock, qui continuent d'être utilisées dans l'exécution en cours du gestionnaire bcm_rx_handler(). Cela entraîne un accès à un bloc de mémoire déjà libéré (use-after-free).
L'attaque consiste à ouvrir deux sockets CAN BCM et à les lier à l'interface vcan. Dans le premier socket, la fonction sendmsg() est appelée avec le drapeau RX_SETUP pour configurer le gestionnaire des messages entrant CAN, tandis que dans le second socket, sendmsg() est appelée pour envoyer un message au premier socket. Après l'arrivée du message, bcm_rx_handler() est déclenché, et l'attaquant choisit le bon moment pour fermer le premier socket, ce qui entraîne l'exécution de bcm_release() et la libération des structures bcm_op et bcm_sock, bien que le traitement de bcm_rx_handler() ne soit pas encore terminé.
Par des manipulations de l'objet bcm_sock, un attaquant peut redéfinir le pointeur de la fonction sk->sk_data_ready(sk), rediriger l'exécution et, en utilisant des techniques de programmation orientée retour (ROP - Return-Oriented Programming), organiser la réécriture du paramètre modprobe_path pour exécuter son code avec des droits root. Lors de l'utilisation de la technique ROP, l'attaquant ne cherche pas à placer son code en mémoire, mais opère avec des morceaux d'instructions machine déjà présents dans les bibliothèques chargées, se terminant par une instruction de retour (généralement les terminaisons des fonctions de bibliothèque). L'exploitation se résume à construire une chaîne d'appels de tels blocs (« gadgets ») pour obtenir la fonctionnalité souhaitée.
Pour l'attaque, un accès pour créer des sockets CAN et une interface réseau vcan configurée sont nécessaires. Les autorisations requises pour mener l'attaque peuvent être obtenues par un utilisateur non privilégié dans des conteneurs créés dans des systèmes avec la prise en charge des espaces de noms d'identifiants d'utilisateur (user namespaces) activée. Par exemple, les user namespaces sont activés par défaut dans Ubuntu et Fedora, mais ne le sont pas dans Debian et RHEL.
Source : opennet.ru
