Une nouvelle vulnérabilité dans l'environnement d'exécution du conteneur CRI-O utilisé par de nombreuses installations Kubernetes permet à un utilisateur malveillant d'obtenir un accès root à l'hôte. La vulnérabilité a été découverte par des chercheurs de CrowdStrike et corrigée peu après par le projet CRI-O.
Cette vulnérabilité a été découverte et rapportée par les chercheurs de CrowdStrike qui l'ont divulgué à CRI-O. Le projet CRI-O a corrigé la vulnérabilité dans un correctif. Surnommé "cr8escape", le bug a un score de 8,8 dans le Common Vulnerability Scoring System (CVSS).
Selon le rapport CVE :
Ce problème permet à toute personne disposant des droits de déployer un pod sur un cluster Kubernetes qui utilise le runtime CRI-O pour obtenir un échappement de conteneur et une exécution de code arbitraire en tant que root sur le nœud du cluster, où le pod malveillant a été déployé
CRI-O est une implémentation de conteneur open source de la Container Runtime Interface (CRI) de Kubernetes. Il a été accepté dans l'incubateur CNCF en 2019 et est utilisé comme alternative à Docker dans certaines installations Kubernetes. Les fournisseurs des Kubernetes gérés qui utilisent CRI-O comme environnement d'exécution incluent OpenShift de Red Hat et l'environnement Cloud Native d'Oracle. Les services gérés les plus connus comme AWS EKS, GKE et Azure AKS utilisent soit Dockershim ou containerd.
Les conteneurs peuvent définir des paramètres de noyau qui sont des espaces de noms et ne peuvent donc affecter que ce conteneur sans affecter les autres conteneurs s'exécutant sur le même hôte. Cela est vrai que le conteneur s'exécute dans Kubernetes ou dans un environnement d'exécution de conteneur autonome. "Kubernetes et les environnements d'exécution de conteneurs qu'il pilote permettent aux pods de mettre à jour ces paramètres de noyau 'sûrs' tout en bloquant l'accès aux autres" - expliquent les chercheurs de CrowdStrike dans leur article.
CRI-O version 1.19 introduit une vulnérabilité qui permet à un utilisateur malveillant de contourner ces mesures de sécurité et de définir des paramètres de noyau arbitraires sur la machine hôte. Le paramètre "kernel.core_pattern" peut être utilisé pour exécuter des commandes en tant que root sur l'hôte. Sous le capot, le projet CRI-O utilise l'utilitaire "pinns" pour définir les options du noyau pour un pod. Cela se fait sans aucune validation, ce qui a conduit à l'exécution de code arbitraire sur l'hôte.
Il convient de noter qu'un utilisateur doit disposer de droits de déploiement de pod sur le runtime ou sur le cluster Kubernetes afin d'exploiter cela. Christophe Tafani-Dereeper, chercheur en sécurité chez DataDog, note que les clusters Kubernetes qui n'ont pas de mesures de sécurité comme Pod Security Admission ou Pod Security Policies activées présentent le même niveau de risque, quelle que soit cette vulnérabilité. Les Pod Security Policies sont toutefois obsolètes depuis Kubernetes 1.21.
Une autre vulnérabilité dans l'outil CLI runc qui a fait surface dans 2019 autorisait l'accès root à l'hôte sous-jacent aux conteneurs malveillants. Kubernetes - la plate-forme et les outils associés - a elle-même eu quelques vulnérabilités signalées et corrigées ces dernières années, et l'accent a été mis de plus en plus sur les guides de durcissement.