Un problème de sécurité a été découvert dans Kubernetes Image Builder où les informations d’identification par défaut sont activées pendant le processus de construction de l’image. Un exploit qui donne la possibilité aux pirates d’obtenir un accès administrateur à un système cible.
Les utilisateurs recourant à des clusters utilisant des images de VM construites avec Kubernetes Image Builder version v0.1.37 ou antérieure doivent s’inquiéter. Un gros souci de sécurité a été découvert dans cet outil permettant de construire des images K8’s : les informations d’identification par défaut sont activées pendant le processus de construction de l’image. « Les images de machines virtuelles construites à l’aide du fournisseur Proxmox ne désactivent pas ces informations d’identification par défaut, et les nœuds utilisant les images résultantes peuvent être accessibles via ces informations d’identification par défaut », prévient le Nist (National Institute of Standards and Technology) du département du Commerce américain.
Ce trou de sécurité ouvre la voie à un accès root via l’utilisation de ces identifiants. A noter que les clusters Kubernetes dont les nœuds utilisant des VM créées via Image Builder sur Proxmox (et son hyperviseur basé sur KVM) sont les plus à risques, la faille CVE-2024-9486 étant classée critique (score CVSS 9.8). Pour les machines virtuelles conçues, déployées ou gérées avec Nutanix, OVA (open virtual machine format), QEMU (logiciel de virtualisation et émulateur open source) ou raw device mapping (mécanisme permettant à une VM d’avoir un accès direct à un LUN sur le sous-système de stockage physique), ne sont pas concernées par ce problème la vulnérabilité (CVE-2024-9594) est à risque modéré (score CVSS 6.3). Pour ces derniers, le risque est réel si un attaquant est capable d’atteindre la machine virtuelle où la construction de l’image a lieu et exploite la vulnérabilité pour modifier l’image au moment où la construction de l’image a lieu. Les machines virtuelles utilisant des images créées par d’autres fournisseurs – VMware ESXi ou vSphere par exemple – ne sont pas affectées.
Une mesure d’atténuation possible
Pour atténuer cette faille – si une montée de version n’est pas possible – une mesure d’atténuation consiste à reconstruire toutes les images affectées en utilisant une version fixe d’Image Builder. Redéployez les images corrigées sur toutes les VM affectées. Avant la mise à jour, cette vulnérabilité peut être atténuée en désactivant le compte builder sur les machines virtuelles concernées : usermod -L builder.
