{"id":103483,"date":"2022-03-06T15:36:45","date_gmt":"2022-03-06T13:36:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera"},"modified":"2022-03-06T15:36:45","modified_gmt":"2022-03-06T13:36:47","slug":"uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera","title":{"rendered":"Vuln\u00e9rabilit\u00e9 dans cgroups v1 permettant de sortir d'un conteneur isol\u00e9","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Des d\u00e9tails sur la vuln\u00e9rabilit\u00e9 (CVE-2022-0492) dans l'impl\u00e9mentation du m\u00e9canisme de limitation des ressources cgroups v1 dans le noyau Linux ont \u00e9t\u00e9 r\u00e9v\u00e9l\u00e9s, qui peut \u00eatre utilis\u00e9e pour sortir des conteneurs isol\u00e9s. Le probl\u00e8me se manifeste \u00e0 partir du noyau Linux 2.6.24 et a \u00e9t\u00e9 corrig\u00e9 dans les versions du noyau 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 et 4.9.301. Les mises \u00e0 jour des paquets dans les distributions peuvent \u00eatre suivies sur ces pages : Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux. <\/p>\n
La vuln\u00e9rabilit\u00e9 est caus\u00e9e par une erreur logique dans le gestionnaire de fichiers release_agent, qui n'effectuait pas les v\u00e9rifications n\u00e9cessaires lors du lancement du gestionnaire avec un ensemble complet de privil\u00e8ges. Le fichier release_agent est utilis\u00e9 pour d\u00e9terminer le programme ex\u00e9cut\u00e9 par le noyau lors de la terminaison d'un processus dans un cgroup. Ce programme s'ex\u00e9cute avec des droits root et avec toutes les \u00ab capacit\u00e9s \u00bb dans l'espace de noms racine. Il \u00e9tait suppos\u00e9 que l'acc\u00e8s \u00e0 la configuration de release_agent \u00e9tait r\u00e9serv\u00e9 \u00e0 l'administrateur, mais en r\u00e9alit\u00e9, les v\u00e9rifications se limitaient \u00e0 la fourniture d'un acc\u00e8s \u00e0 l'utilisateur root, ce qui ne permettait pas d'exclure la modification des param\u00e8tres depuis un conteneur ou par un utilisateur root sans droits d'administrateur (CAP_SYS_ADMIN). <\/p>\n
Auparavant, une telle fonctionnalit\u00e9 n'aurait pas \u00e9t\u00e9 per\u00e7ue comme une vuln\u00e9rabilit\u00e9, mais la situation a chang\u00e9 avec l'\u00e9mergence des espaces de noms d'identifiants utilisateur (user namespaces), qui permettent de cr\u00e9er dans les conteneurs des utilisateurs root distincts, ne chevauchant pas l'utilisateur root de l'environnement principal. Par cons\u00e9quent, pour effectuer une attaque, il suffit dans un conteneur ayant son propre utilisateur root dans un espace de noms d'identifiants utilisateur distinct d'injecter son propre gestionnaire release_agent, qui sera ex\u00e9cut\u00e9 avec tous les privil\u00e8ges de l'environnement principal une fois le processus termin\u00e9. <\/p>\n
Par d\u00e9faut, cgroupfs est mont\u00e9 dans le conteneur en mode lecture seule, mais il n'y a pas de probl\u00e8me \u00e0 remonter ce pseudo-syst\u00e8me de fichiers en mode \u00e9criture avec des droits CAP_SYS_ADMIN ou en cr\u00e9ant, \u00e0 l'aide de l'appel syst\u00e8me unshare, un conteneur imbriqu\u00e9 avec un espace de noms utilisateur distinct, o\u00f9 les droits CAP_SYS_ADMIN sont disponibles pour le conteneur cr\u00e9\u00e9.
<\/center> <\/p>\n
Une attaque peut \u00eatre r\u00e9alis\u00e9e en ayant des privil\u00e8ges root dans un conteneur isol\u00e9 ou en lan\u00e7ant un conteneur sans le drapeau no_new_privs, qui interdit l'acquisition de privil\u00e8ges suppl\u00e9mentaires. La prise en charge des espaces de noms utilisateur doit \u00eatre activ\u00e9e dans le syst\u00e8me (activ\u00e9e par d\u00e9faut dans Ubuntu et Fedora, mais pas activ\u00e9e dans Debian et RHEL) et un acc\u00e8s au cgroup racine v1 doit \u00eatre pr\u00e9sent (par exemple, Docker lance des conteneurs dans le cgroup RDMA racine). Une attaque est \u00e9galement possible en disposant des privil\u00e8ges CAP_SYS_ADMIN, auquel cas la prise en charge des espaces de noms utilisateur et l'acc\u00e8s \u00e0 la hi\u00e9rarchie cgroup racine v1 ne sont pas requis. <\/p>\n
En plus de l'exit d'un conteneur isol\u00e9, la vuln\u00e9rabilit\u00e9 permet \u00e9galement aux processus ex\u00e9cut\u00e9s par l'utilisateur root sans \u00ab capacit\u00e9s \u00bb ou \u00e0 tout utilisateur avec les droits CAP_DAC_OVERRIDE (pour l'attaque, un acc\u00e8s au fichier \/sys\/fs\/cgroup\/*\/release_agent, qui appartient \u00e0 root, est requis), d'acc\u00e9der \u00e0 toutes les \u00ab capacit\u00e9s \u00bb syst\u00e8me. <\/p>\n
Il est \u00e0 noter que la vuln\u00e9rabilit\u00e9 ne peut pas \u00eatre exploit\u00e9e lorsque des m\u00e9canismes de protection tels que Seccomp, AppArmor ou SELinux sont appliqu\u00e9s pour une isolation suppl\u00e9mentaire des conteneurs, car Seccomp bloque l'appel syst\u00e8me unshare(), et AppArmor et SELinux n'autorisent pas le montage de cgroupfs en mode \u00e9criture. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Vuln\u00e9rabilit\u00e9](\"\/wp-content\/uploads\/2022\/03\/710b37582c444cc4be7d6ae4695c8afe.jpg\")
<\/center> <\/p>\n