{"id":101712,"date":"2021-10-21T10:22:53","date_gmt":"2021-10-21T08:22:53","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/raskryta-tehnika-ekspluataczii-uyazvimosti-v-tty-podsisteme-yadra-linux"},"modified":"2021-10-21T10:22:53","modified_gmt":"2021-10-21T08:22:53","slug":"raskryta-tehnika-ekspluataczii-uyazvimosti-v-tty-podsisteme-yadra-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/raskryta-tehnika-ekspluataczii-uyazvimosti-v-tty-podsisteme-yadra-linux","title":{"rendered":"La technique d'exploitation de la vuln\u00e9rabilit\u00e9 dans le sous-syst\u00e8me tty du noyau Linux a \u00e9t\u00e9 divulgu\u00e9e.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Des chercheurs de l'\u00e9quipe Google Project Zero ont publi\u00e9 une m\u00e9thode d'exploitation de la vuln\u00e9rabilit\u00e9 (CVE-2020-29661) dans l'impl\u00e9mentation du gestionnaire ioctl TIOCSPGRP de la sous-syst\u00e8me tty du noyau Linux, et ont \u00e9galement examin\u00e9 en d\u00e9tail les m\u00e9canismes de protection qui pourraient bloquer de telles vuln\u00e9rabilit\u00e9s. <\/p>\n
L'erreur probl\u00e9matique a \u00e9t\u00e9 corrig\u00e9e dans le noyau Linux le 3 d\u00e9cembre de l'ann\u00e9e derni\u00e8re. Le probl\u00e8me se manifeste dans les noyaux jusqu'\u00e0 la version 5.9.13, mais la plupart des distributions ont corrig\u00e9 le probl\u00e8me dans les mises \u00e0 jour des paquets avec noyau propos\u00e9es l'ann\u00e9e derni\u00e8re (Debian, RHEL, SUSE, Ubuntu, Fedora, Arch). Une vuln\u00e9rabilit\u00e9 similaire (CVE-2020-29660) a \u00e9t\u00e9 trouv\u00e9e simultan\u00e9ment dans l'impl\u00e9mentation de l'appel ioctl TIOCGSID, mais elle a \u00e9galement \u00e9t\u00e9 largement corrig\u00e9e. <\/p>\n
Le probl\u00e8me provient d'une erreur dans l'installation des verrous, entra\u00eenant une condition de concurrence dans le code drivers\/tty\/tty_jobctrl.c, qui a \u00e9t\u00e9 exploit\u00e9 pour cr\u00e9er des conditions d'acc\u00e8s \u00e0 la m\u00e9moire apr\u00e8s sa lib\u00e9ration (use-after-free), exploitable depuis l'espace utilisateur par le biais de manipulations de l'appel ioctl TIOCSPGRP. Un exploit fonctionnel a \u00e9t\u00e9 d\u00e9montr\u00e9 pour obtenir des privil\u00e8ges \u00e9lev\u00e9s sur Debian 10 avec le noyau 4.19.0-13-amd64. <\/p>\n
Dans l'article publi\u00e9, l'accent n'est pas tant mis sur la technique de cr\u00e9ation d'un exploit fonctionnel, mais sur les outils que le noyau dispose pour se prot\u00e9ger contre de telles vuln\u00e9rabilit\u00e9s. La conclusion est peu encourageante, les m\u00e9thodes telles que la segmentation de la m\u00e9moire en tas et le contr\u00f4le des acc\u00e8s \u00e0 la m\u00e9moire apr\u00e8s sa lib\u00e9ration ne sont pas appliqu\u00e9es en pratique, car elles entra\u00eenent une diminution des performances, et la protection bas\u00e9e sur CFI (Control Flow Integrity), qui bloque les exploits \u00e0 des stades avanc\u00e9s de l'attaque, n\u00e9cessite des am\u00e9liorations. <\/p>\n
En consid\u00e9rant ce qui pourrait changer la situation \u00e0 long terme, l'accent est mis sur l'application de v\u00e9rificateurs statiques avanc\u00e9s ou sur l'utilisation de langages assurant une gestion s\u00fbre de la m\u00e9moire, tels que Rust et les dialectes du langage C avec des annotations \u00e9tendues (par exemple, Checked C), au moment de la compilation pour v\u00e9rifier l'\u00e9tat des verrous, des objets et des pointeurs. Parmi les m\u00e9thodes de protection, on mentionne \u00e9galement l'activation du mode panic_on_oops, la conversion des structures du noyau en mode lecture seule et la limitation de l'acc\u00e8s aux appels syst\u00e8me \u00e0 l'aide de m\u00e9canismes tels que seccomp. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"