Des vulnérabilités du noyau Linux exploitées à distance via Bluetooth

Une vulnérabilité (CVE-2022-42896) a été identifiée dans le noyau Linux, qui peut potentiellement être utilisée pour organiser l'exécution de code à distance au niveau du noyau en envoyant un paquet L2CAP spécialement conçu via Bluetooth. De plus, un autre problème similaire a été identifié (CVE-2022-42895) dans le gestionnaire L2CAP, qui peut entraîner une fuite du contenu de la mémoire du noyau dans les paquets contenant des informations de configuration. La première vulnérabilité est apparue depuis août 2014 (noyau 3.16), et la seconde depuis octobre 2011 (noyau 3.0). Les vulnérabilités ont été corrigées dans les versions 6.1.0, 6.0.8, 4.9.333, 4.14.299, 4.19.265, 5.4.224, 5.10.154 et 5.15.78 du noyau Linux. Vous pouvez suivre les correctifs dans les distributions sur les pages suivantes : Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch.

Pour démontrer la possibilité de mener une attaque à distance, des prototypes d'exploits ont été publiés qui fonctionnent sur Ubuntu 22.04. Pour mener une attaque, l'attaquant doit être à portée Bluetooth : aucun pré-appairage n'est requis, mais Bluetooth doit être actif sur l'ordinateur. Pour une attaque, il suffit de connaître l’adresse MAC de l’appareil de la victime, qui peut être déterminée par reniflage ou, sur certains appareils, calculée en fonction de l’adresse MAC Wi-Fi.

La première vulnérabilité (CVE-2022-42896) est causée par l'accès à une zone mémoire déjà libérée (use-after-free) dans l'implémentation des fonctions l2cap_connect et l2cap_le_connect_req - après avoir créé un canal via le rappel new_connection, aucun verrou n'a été défini. pour cela, mais une minuterie a été définie (__set_chan_timer ), à l'expiration du délai d'attente, appelant la fonction l2cap_chan_timeout et effaçant le canal sans vérifier l'achèvement du travail avec le canal dans les fonctions l2cap_le_connect*.

Le délai d'attente par défaut est de 40 secondes et il a été supposé qu'une condition de concurrence critique ne pouvait pas se produire avec un tel délai, mais il s'est avéré qu'en raison d'une autre erreur dans le gestionnaire SMP, il était possible d'appeler instantanément le minuteur et d'obtenir un condition de course. Un problème dans l2cap_le_connect_req peut conduire à une fuite de mémoire du noyau, et dans l2cap_connect cela peut conduire à l'écrasement du contenu de la mémoire et à l'exécution de son code. Le premier type d'attaque peut être réalisé avec Bluetooth LE 4.0 (depuis 2009), le second avec Bluetooth BR/EDR 5.2 (depuis 2020).

La deuxième vulnérabilité (CVE-2022-42895) est causée par une fuite de mémoire résiduelle dans la fonction l2cap_parse_conf_req, qui peut être utilisée pour obtenir à distance des informations sur les pointeurs vers les structures du noyau en envoyant des requêtes de configuration spécialement conçues. La fonction l2cap_parse_conf_req utilisait la structure l2cap_conf_efs, pour laquelle la mémoire allouée n'était pas pré-initialisée et en manipulant l'indicateur FLAG_EFS_ENABLE il était possible d'inclure les anciennes données de la pile dans le paquet. Le problème n'apparaît que sur les systèmes où le noyau est construit avec l'option CONFIG_BT_HS (désactivée par défaut, mais activée sur certaines distributions, comme Ubuntu). Une attaque réussie nécessite également de définir le paramètre HCI_HS_ENABLED via l'interface de gestion sur true (non utilisé par défaut).

Source: opennet.ru

Ajouter un commentaire