bgeesaman/subpath-exploitAnalyse de CVE-2017-1002101 avec un exemple d'"exploit"/escape
Après avoir entendu parler du problème et suivi ce guide, j'ai voulu explorer les choses un peu plus. Ce dépôt contient quelques déploiements de pods et des scripts shell d'assistance qui démontrent le mécanisme d'attaque de la manière la plus simple possible, afin que les administrateurs et opérateurs Kubernetes puissent pleinement comprendre la gravité et les risques potentiels. Vous devez être un utilisateur authentifié ou pouvoir contrôler la spécification/le modèle d'un pod lors de sa création, donc cet échappement n'est probablement pas anonyme à moins d'être combiné avec d'autres attaques comme celle-ci.
Lorsque le Kubelet monte un volume/secret/configmap, etc., il suit incorrectement les liens symboliques à l'intérieur du volume vers des emplacements en dehors du périmètre où il le devrait. Parce que le Kubelet s'exécute en tant que root, cela signifie qu'il peut être piégé pour monter des parties privilégiées du système de fichiers de l'hôte à l'intérieur du conteneur d'un pod non privilégié.
Mon approche a été d'utiliser un seul pod avec deux conteneurs "normaux". Un conteneur crée le lien symbolique vers / ou /home/ubuntu et l'autre fait des crashloop jusqu'à ce que cela réussisse (forçant le volume à être remonté et suivant ce chemin de lien symbolique), permettant à l'utilisateur d'exécuter exec dans le second conteneur et d'accéder au point de montage.
Remarque : Ces exemples fonctionnent sans modification sur un hôte Ubuntu 16.04, mais ils peuvent être facilement adaptés pour d'autres configurations.
./run-as-root.sh si votre cluster est relativement "standard"../run-as-root-no-chroot.sh ou ./run-as-user-1000.sh pour d'autres variantes.
C'est vraiment une situation où il est impératif d'appliquer le correctif. Malheureusement, les contournements listés ici ne sont pas vraiment pratiques pour la plupart des gens. Presque toutes les versions antérieures sont vulnérables.