Vulnérabilité dans cgroups v1 permettant de sortir d'un conteneur isolé

Des détails sur la vulnérabilité (CVE-2022-0492) dans l'implémentation du mécanisme de limitation des ressources cgroups v1 dans le noyau Linux ont été révélés, qui peut être utilisée pour sortir des conteneurs isolés. Le problème se manifeste à partir du noyau Linux 2.6.24 et a été corrigé 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 à jour des paquets dans les distributions peuvent être suivies sur ces pages : Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.

La vulnérabilité est causée par une erreur logique dans le gestionnaire de fichiers release_agent, ce qui empêche l'exécution des vérifications appropriées lors du lancement du gestionnaire avec un ensemble complet de privilèges. Le fichier release_agent est utilisé pour déterminer le programme que le noyau exécute à la fin du processus dans le cgroup. Ce programme est exécuté avec des droits root et tous les « capabilities » dans l'espace de noms racine. On supposait que l'accès à la configuration de release_agent n'était disponible que pour l'administrateur, mais en réalité, les vérifications se limitaient à accorder l'accès à l'utilisateur root, ce qui n'exclut pas la modification de la configuration depuis un conteneur ou par un utilisateur root sans droits d'administrateur (CAP_SYS_ADMIN).

Auparavant, une telle fonctionnalité n'aurait pas été perçue comme une vulnérabilité, mais la situation a changé avec l'émergence des espaces de noms d'identifiants utilisateur (user namespaces), qui permettent de créer dans les conteneurs des utilisateurs root distincts, ne chevauchant pas l'utilisateur root de l'environnement principal. Par conséquent, 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écuté avec tous les privilèges de l'environnement principal une fois le processus terminé.

Par défaut, cgroupfs est monté dans le conteneur en mode lecture seule, mais il n'y a pas de problème à remonter ce pseudo-système de fichiers en mode écriture avec des droits CAP_SYS_ADMIN ou en créant, à l'aide de l'appel système unshare, un conteneur imbriqué avec un espace de noms utilisateur distinct, où les droits CAP_SYS_ADMIN sont disponibles pour le conteneur créé.

Une attaque peut être réalisée en ayant des privilèges root dans un conteneur isolé ou en lançant un conteneur sans le drapeau no_new_privs, qui interdit l'acquisition de privilèges supplémentaires. La prise en charge des espaces de noms utilisateur doit être activée dans le système (activée par défaut dans Ubuntu et Fedora, mais pas activée dans Debian et RHEL) et un accès au cgroup racine v1 doit être présent (par exemple, Docker lance des conteneurs dans le cgroup RDMA racine). Une attaque est également possible en disposant des privilèges CAP_SYS_ADMIN, auquel cas la prise en charge des espaces de noms utilisateur et l'accès à la hiérarchie cgroup racine v1 ne sont pas requis.

En plus de sortir d'un conteneur isolé, la vulnérabilité permet également aux processus lancés par l'utilisateur root sans « capabilities » ou à tout utilisateur disposant des droits CAP_DAC_OVERRIDE (un accès au fichier /sys/fs/cgroup/*/release_agent, qui appartient à root, est requis pour l'attaque), d'accéder à toutes les « capabilities » système.

Il est à noter que la vulnérabilité ne peut pas être exploitée lorsque des mécanismes de protection tels que Seccomp, AppArmor ou SELinux sont appliqués pour une isolation supplémentaire des conteneurs, car Seccomp bloque l'appel système unshare(), et AppArmor et SELinux n'autorisent pas le montage de cgroupfs en mode écriture.

Source : opennet.ru