{"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\/fr\/blog\/news\/uyazvimost-v-yadre-linux-zatragivayushhaya-setevoj-protokol-can-bcm","title":{"rendered":"Vuln\u00e9rabilit\u00e9 dans le noyau Linux touchant le protocole r\u00e9seau CAN BCM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Une vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 d\u00e9tect\u00e9e dans le noyau Linux (CVE-2021-3609), permettant \u00e0 un utilisateur local d'\u00e9lever ses privil\u00e8ges dans le syst\u00e8me. Ce probl\u00e8me est caus\u00e9 par une condition de course dans l'impl\u00e9mentation du protocole CAN BCM et se manifeste dans les versions du noyau Linux de 2.6.25 \u00e0 5.13-rc6. Dans les distributions, le probl\u00e8me demeure non corrig\u00e9 (RHEL, Fedora, Debian, Ubuntu, SUSE, Arch). <\/p>\n
Le chercheur ayant d\u00e9couvert la vuln\u00e9rabilit\u00e9 a r\u00e9ussi \u00e0 pr\u00e9parer un exploit pour obtenir des droits root sur les syst\u00e8mes avec des noyaux Linux 5.4 et plus r\u00e9cents, y compris une d\u00e9monstration de la possibilit\u00e9 d'ex\u00e9cuter une attaque sur Ubuntu 20.04.02 LTS. Il n'est pas exclu que l'exploit puisse \u00eatre adapt\u00e9 pour fonctionner avec des noyaux plus anciens (dans le noyau 5.4, le code CAN BCM (net\/can\/bcm.c) a \u00e9t\u00e9 converti de hrtimer_tasklet \u00e0 HRTIMER_MODE_SOFT). <\/p>\n
Le protocole CAN BCM permet d'enregistrer un gestionnaire de messages personnalis\u00e9 pour les messages entrant via le bus CAN (controller area network) et de l'attacher \u00e0 un socket r\u00e9seau sp\u00e9cifique. Lorsqu'un message entrant arrive, la fonction bcm_rx_handler() est appel\u00e9e. L'attaquant peut tirer parti de la condition de course et provoquer la fermeture du socket r\u00e9seau en m\u00eame temps que l'ex\u00e9cution de bcm_rx_handler(). Lors de la fermeture du socket, la fonction bcm_release() est appel\u00e9e, lib\u00e9rant la m\u00e9moire allou\u00e9e pour les structures bcm_op et bcm_sock, qui continuent d'\u00eatre utilis\u00e9es dans l'ex\u00e9cution en cours du gestionnaire bcm_rx_handler(). Cela entra\u00eene un acc\u00e8s \u00e0 un bloc de m\u00e9moire d\u00e9j\u00e0 lib\u00e9r\u00e9 (use-after-free). <\/p>\n
L'attaque consiste \u00e0 ouvrir deux sockets CAN BCM et \u00e0 les lier \u00e0 l'interface vcan. Dans le premier socket, la fonction sendmsg() est appel\u00e9e avec le drapeau RX_SETUP pour configurer le gestionnaire des messages entrant CAN, tandis que dans le second socket, sendmsg() est appel\u00e9e pour envoyer un message au premier socket. Apr\u00e8s l'arriv\u00e9e du message, bcm_rx_handler() est d\u00e9clench\u00e9, et l'attaquant choisit le bon moment pour fermer le premier socket, ce qui entra\u00eene l'ex\u00e9cution de bcm_release() et la lib\u00e9ration des structures bcm_op et bcm_sock, bien que le traitement de bcm_rx_handler() ne soit pas encore termin\u00e9. <\/p>\n
Gr\u00e2ce \u00e0 des manipulations du contenu de bcm_sock, un attaquant peut red\u00e9finir le pointeur vers la fonction sk->sk_data_ready(sk), rediriger l'ex\u00e9cution et, en utilisant des techniques de programmation orient\u00e9e retour (ROP - Return-Oriented Programming), organiser la r\u00e9\u00e9criture du param\u00e8tre modprobe_path pour ex\u00e9cuter son code avec les droits root. Lors de l'utilisation de la technique ROP, l'attaquant ne tente pas de placer son code en m\u00e9moire, mais op\u00e8re avec des fragments d'instructions machine d\u00e9j\u00e0 pr\u00e9sents dans les biblioth\u00e8ques charg\u00e9es, se terminant par une instruction de retour de contr\u00f4le (comme c'est g\u00e9n\u00e9ralement le cas pour les fonctions de biblioth\u00e8que). Le fonctionnement de l'exploit consiste \u00e0 construire une cha\u00eene d'appels de tels blocs (\u00ab gadgets \u00bb) pour obtenir la fonctionnalit\u00e9 souhait\u00e9e.
<\/center> <\/p>\n
Pour l'attaque, un acc\u00e8s pour cr\u00e9er des sockets CAN et une interface r\u00e9seau vcan configur\u00e9e sont n\u00e9cessaires. Les autorisations requises pour mener l'attaque peuvent \u00eatre obtenues par un utilisateur non privil\u00e9gi\u00e9 dans des conteneurs cr\u00e9\u00e9s dans des syst\u00e8mes avec la prise en charge des espaces de noms d'identifiants d'utilisateur (user namespaces) activ\u00e9e. Par exemple, les user namespaces sont activ\u00e9s par d\u00e9faut dans Ubuntu et Fedora, mais ne le sont pas dans Debian et RHEL. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Vuln\u00e9rabilit\u00e9](\"\/wp-content\/uploads\/2021\/06\/60534f0194a819c8401abf2ec53b3a9a.png\")
<\/center> <\/p>\n