Les détails d'une vulnérabilité (CVE-2022-0492) dans l'implémentation du mécanisme de limitation des ressources cgroups v1 dans le noyau Linux, qui peut être utilisée pour échapper aux conteneurs isolés, ont été divulgués. Le problème est présent depuis le noyau Linux 2.6.24 et a été corrigé dans les versions 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 et 4.9.301. Vous pouvez suivre les publications des mises à jour de paquets dans les distributions sur ces pages : Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
La vulnérabilité est due à une erreur logique dans le gestionnaire de fichiers release_agent qui ne parvient pas à effectuer les vérifications appropriées lors de l'exécution du gestionnaire avec tous les privilèges. Le fichier release_agent est utilisé pour définir le programme à exécuter par le noyau lorsqu'un processus dans un groupe de contrôle est terminé. Ce programme s'exécute en tant que root et avec toutes les « capacités » dans l'espace de noms racine. On supposait que seul l'administrateur avait accès au paramètre release_agent, mais en réalité les contrôles se limitaient à accorder l'accès à l'utilisateur root, ce qui n'excluait pas que le paramètre soit modifié depuis le 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'avènement des espaces de noms d'utilisateurs (espaces de noms d'utilisateurs), qui vous permettent de créer des utilisateurs root distincts dans des conteneurs qui ne chevauchent pas l'utilisateur root du environnement principal. Par conséquent, pour une attaque, il suffit de connecter votre gestionnaire release_agent dans un conteneur qui a son propre utilisateur root dans un espace d'ID utilisateur distinct, qui, une fois le processus terminé, sera exécuté avec tous les privilèges de l'environnement principal.
Par défaut, cgroupfs est monté dans un conteneur en mode lecture seule, mais il n'y a aucun problème pour remonter ce pseudofs en mode écriture si vous disposez des droits CAP_SYS_ADMIN ou en créant un conteneur imbriqué avec un espace de noms utilisateur distinct à l'aide de l'appel système unshare, dans lequel Les droits CAP_SYS_ADMIN sont disponibles pour le conteneur créé.
L'attaque peut être menée si vous disposez des privilèges root dans un conteneur isolé ou lors de l'exécution d'un conteneur sans l'indicateur no_new_privs, qui interdit l'obtention de privilèges supplémentaires. Le système doit avoir la prise en charge des espaces de noms utilisateur activée (activée par défaut dans Ubuntu et Fedora, mais non activée dans Debian et RHEL) et avoir accès au groupe de contrôle racine v1 (par exemple, Docker exécute des conteneurs dans le groupe de contrôle RDMA racine). L'attaque est également possible si vous disposez des privilèges CAP_SYS_ADMIN, auquel cas la prise en charge des espaces de noms utilisateur et l'accès à la hiérarchie racine du groupe de contrôle v1 ne sont pas requis.
En plus de s'échapper d'un conteneur isolé, la vulnérabilité permet également de lancer des processus par un utilisateur root sans "capacités" ou par tout utilisateur disposant des droits CAP_DAC_OVERRIDE (l'attaque nécessite l'accès au fichier /sys/fs/cgroup/*/release_agent, qui est appartenant à root) pour accéder à toutes les « capacités » systémiques.
Il est à noter que la vulnérabilité ne peut pas être exploitée lors de l'utilisation des mécanismes de protection Seccomp, AppArmor ou SELinux pour une isolation supplémentaire des conteneurs, car Seccomp bloque l'accès à l'appel système unshare() et AppArmor et SELinux ne permettent pas de monter cgroupfs en mode écriture.
Source: opennet.ru