Des détails sont apparus sur une vulnérabilité de haute gravité désormais corrigée dans le noyau Linux qui pourrait potentiellement être utilisée pour échapper à un conteneur afin d’exécuter des commandes arbitraires sur l’hôte du conteneur.

La lacune réside dans une fonctionnalité du noyau Linux appelée groupes de contrôleégalement appelé cgroups version 1 (v1), qui permet d’organiser les processus en groupes hiérarchiques, ce qui permet de limiter et de surveiller efficacement l’utilisation des ressources telles que le processeur, la mémoire, les E/S disque et le réseau.

Suivi comme CVE-2022-0492 (score CVSS : 7,0), la publier préoccupations une Cas de élévation de privilèges dans la fonctionnalité release_agent de cgroups v1, un script qui est exécuté après l’arrêt de tout processus dans le cgroup.

« Le problème se distingue comme l’une des escalades de privilèges Linux les plus simples découvertes ces derniers temps : le noyau Linux a exposé par erreur une opération privilégiée à des utilisateurs non privilégiés », a déclaré Yuval Avrahami, chercheur à l’unité 42. mentionné dans un rapport publié cette semaine.

le page de manuel for cgroups explique sa fonction comme suit –

Que le programme release_agent soit appelé ou non lorsqu’un groupe de contrôle particulier devient vide est déterminé par la valeur du fichier notify_on_release dans le répertoire de groupe de contrôle correspondant. Si ce fichier contient la valeur 0, le programme release_agent n’est pas invoqué. S’il contient la valeur 1, le programme release_agent est appelé. La valeur par défaut pour ce fichier dans le cgroup racine est 0.

Plus précisément, l’équipe de renseignement sur les menaces de Palo Alto Networks a noté que le bogue est la conséquence d’une vérification manquante pour vérifier si le processus définissant le fichier release_agent avait des privilèges administratifs, le rendant ainsi mûr pour une exploitation potentielle.

En d’autres termes, si ce fichier release_agent est écrasé par un attaquant, le noyau peut être contraint d’appeler un binaire arbitraire configuré dans l’agent de publication avec les autorisations les plus élevées possibles – un scénario qui pourrait effectivement permettre une prise de contrôle complète de la machine.

Il convient toutefois de noter que seuls les processus dotés de privilèges « root » peuvent écrire dans le fichier, ce qui signifie que la vulnérabilité permet uniquement aux processus root d’élever les privilèges.

« A première vue, une vulnérabilité d’escalade de privilèges qui ne peut être exploitée que par l’utilisateur root peut sembler bizarre », a expliqué Avrahami. « L’exécution en tant que root ne signifie pas nécessairement un contrôle total sur la machine : il existe une zone grise entre l’utilisateur root et les privilèges complets qui incluent les capacités, les espaces de noms et les conteneurs. Dans ces scénarios où un processus root n’a pas le contrôle total sur la machine , CVE-2022-0492 devient une vulnérabilité sérieuse. »

Bien que les conteneurs fonctionnant avec AppArmor ou SELinux sont protégés de la faille, il est recommandé aux utilisateurs de appliquer la correctifs à la lumière du fait qu’il pourrait être exploité par d’autres processus hôtes malveillants pour élever les privilèges.

C’est loin d’être la première fois que release_agent apparaît comme un vecteur d’attaque. En juillet 2017, le chercheur de Google Project Zero Felix Wilhelm démontré un exploit de preuve de concept (PoC) « rapide et sale » tirant parti de la fonctionnalité pour sortir des conteneurs Kubernetes et Docker privilégiés.

Puis en novembre 2021, la société de sécurité cloud Aqua divulgué détails d’une campagne d’extraction de crypto-monnaie qui a utilisé exactement la même technique d’échappement de conteneur pour déposer le mineur de pièces XMRig sur des hôtes infectés, ce qui en fait le premier exemple enregistré d’exploitation dans le monde réel.

« CVE-2022-0492 marque une autre vulnérabilité Linux qui peut être exploitée pour l’échappement de conteneurs », a conclu Avrahami. « Heureusement, les environnements qui suivent les meilleures pratiques sont protégés contre cette vulnérabilité. Les environnements avec des contrôles de sécurité laxistes hébergeant des conteneurs non fiables ou exposés publiquement sont, sans surprise, à haut risque. »