La dernière version de Kubernetes publiée le mois dernier corrige toute une classe de vulnérabilités à partir desquelles des attaquants pouvaient abuser de la propriété subPath des fichiers de configuration YAML pour exécuter des commandes malveillantes sur les hôtes Windows. « La vulnérabilité permet l'exécution de code à distance avec des privilèges SYSTEM sur tous les terminaux Windows au sein d'un cluster Kubernetes », a déclaré Tomer Peled, chercheur chez Akamai, à propos de la vulnérabilité qu'il a trouvée et qui a débouché sur la découverte de deux autres problèmes similaires. « Pour exploiter cette vulnérabilité, l'attaquant doit appliquer un fichier YAML malveillant sur le cluster », a ajouté le chercheur.

Les fichier de configuration vulnérables

Un très grand nombre d’entreprises utilisent le système d'orchestration de cluster de conteneurs Kubernetes pour automatiser le déploiement et la gestion des applications exécutées dans des conteneurs. Et c’est le langage YAML qui sert à écrire des fichiers de configuration et d'autres fichiers de gestion pour Kubernetes. Il était donc assez logique qu'il soit une cible pour les attaquants potentiels, car il offre un moyen direct d'envoyer des données utilisateur au moteur Kubernetes pour qu'elles soient analysées et interprétées. Les problèmes de parsing de YAML ont déjà conduit à des brèches dans Kubernetes. Par exemple, la CVE-2022-1471 générant  dans l'analyseur SnakeYaml a eu un impact sur le client Java de Kubernetes. C’est aussi le cas de la CVE-2021-25749 capable d'inclure des noms d'utilisateur mal orthographiés dans un fichier YAML, entraînant ainsi l'exécution de charges de travail en tant que root.

Et ce n’est pas tout : deux vulnérabilités CVE-2017-1002101 et CVE-2021-25741 combinées avec des liens symboliques (symlinks) ont montré qu’il était possible d’utiliser la sous-propriété subPath d'un fichier YAML pour accéder à des fichiers en dehors du conteneur, rompant ainsi l'isolation. Ces deux dernières failles ont donné à Tomer Peled l'idée d'approfondir le sujet. Grâce à une propriété appelée « Volume », Kubernetes peut monter un répertoire depuis le système hôte à l'intérieur d'un conteneur. Cette fonctionnalité largement utilisée s'accompagne de plusieurs sous-propriétés qui définissent le chemin du répertoire sur l'hôte et celui de montage à l'intérieur du conteneur. Le mountPath possède en outre une propriété subPath qui, lorsqu'elle est fournie dans un fichier YAML, est traitée par kubelet, un service central de Kubernetes.

Le traitement des chemins d'accès pointé du doigt

Le chercheur d’Akamai a découvert que lorsque la chaîne subPath est traitée, kubelet vérifie également s'il s'agit d'un lien symbolique, conformément aux défenses mises en place pour les anciennes vulnérabilités. Sauf qu’il le fait par le biais d'une commande PowerShell invoquée par l'appel de fonction « exec.Command ». Or, un attaquant peut attacher du code PowerShell à la chaîne subPath et l'exécuter. « Avec PowerShell, les utilisateurs sont capables d’évaluer les valeurs à l'intérieur des chaînes avant qu'elles ne soient utilisées », a précisé le chercheur. « Cela peut se faire en ajoutant $() à la chaîne [...]. N'importe quelle commande PowerShell peut être insérée entre les parenthèses et sera évaluée - comme $(Start-Process cmd), $(Invoke-Expression exp), et autres traitements PowerShell ».

Fichier YAML avec injection de commande dans le paramètre subPath. (Crédit Photo : Akamai)

Ainsi, par exemple, si un attaquant fournit un fichier YAML à un nœud Kubernetes qui fonctionne sous Windows avec un sous-chemin qui inclut $(Start-Process cmd), celui-ci sera envoyé à PowerShell par kubelet pendant le processus de validation du chemin et sera exécuté avec les privilèges Windows du service kubelet - SYSTEM. Cette faille est désormais répertoriée avec la référence CVE-2023-3676 et a été corrigée dans Kubernetes 1.28, mais elle a également conduit à la découverte et à la correction de deux autres brèchess similaires d'injection de commande référencées CVE-2023-3955 et CVE-2023-3893. La faille a un impact sur Kubernetes sous Windows dans sa configuration par défaut, mais l'attaquant doit obtenir des privilèges d'application sur un nœud.

Atténuer la vulnérabilité basée sur YAML

« L'équipe Kubernetes a choisi de corriger cette classe de vulnérabilités en passant des paramètres à partir de variables d'environnement plutôt qu'à partir d'entrées utilisateur », a observé Tomer Peled. « En transmettant les valeurs de cette manière, les paramètres sont traités comme des chaînes de caractères - par conséquent, ils ne seront pas évalués comme des expressions par PowerShell. S'ils ne peuvent pas mettre à jour immédiatement la version corrigée, les administrateurs peuvent désactiver l'utilisation de Volume.Subpath, mais cela désactivera également une fonctionnalité couramment utilisée. Une autre option consiste à utiliser l'Open Policy Agent (OPA), un agent open source qui peut prendre des mesures basées sur des politiques en fonction des données reçues.

Les administrateurs peuvent créer des règles pour bloquer la mise en œuvre de certains fichiers YAML à l'aide du langage Rego dans l'OPA, et Akamai fournit un exemple d'une telle règle de blocage dans son article de blog. Le chercheur recommande enfin d'utiliser le contrôle d'accès basé sur les rôles (Role-based Access Control, RBAC) pour limiter le nombre d'utilisateurs pouvant effectuer des actions sur un cluster.