Lorsqu'un conteneur est correctement verrouillé, sans capabilities supplémentaires, sans montages sensibles et sans namespaces partagés, s'en évader exige une vulnérabilité. Deux surfaces comptent. La première est le runtime de conteneur lui-même : runc, containerd et CRI-O s'exécutent en tant que root sur l'hôte et manipulent des données contrôlées par l'attaquant (contenu d'image, specs de processus, chemins de fichiers) pendant les phases create, start et exec, de sorte qu'une faille à cet endroit s'exécute sur l'hôte par construction. La seconde est le noyau hôte, partagé par chaque conteneur quelle que soit l'isolation, de sorte qu'un bug du noyau qu'un processus conteneurisé peut atteindre est un bug du noyau sur l'hôte.
Identifiez les versions qui déterminent quelles failles s'appliquent :
runc --version 2>/dev/null; containerd --version 2>/dev/null; crictl version 2>/dev/null
uname -r # host kernel release gates the kernel bugs
cat /proc/self/uid_map # user-namespace reach for unprivileged kernel bugs
Sous-thèmes#
- runc and containerd exploits : failles de runtime et de shim accessibles depuis une image ou une charge de travail forgée.
- Kernel exploits : vulnérabilités du noyau partagé déclenchables depuis un conteneur.