runc est le runtime OCI de référence qui crée et entre réellement dans les conteneurs ; containerd et CRI-O se situent au-dessus de lui et gèrent les images, les shims et le cycle de vie. Tous s'exécutent en tant que root sur l'hôte, et tous manipulent des données que le conteneur contrôle : le système de fichiers de l'image, la spec de processus, les répertoires de travail, les chemins de montage et les annotations. Un bug dans la façon dont l'un d'eux traite ces données pendant create, start ou exec s'exécute avec le privilège root de l'hôte, il s'agit donc d'évasions complètes plutôt que d'escalades.
Identifiez les versions du runtime, qui déterminent quelle faille s'applique :
runc --version 2>/dev/null
containerd --version 2>/dev/null
crictl version 2>/dev/null
cat /proc/self/cgroup # hints at the managing runtime
Sous-thèmes#
- runc /proc/self/exe overwrite : écraser le binaire runc de l'hôte pendant exec.
- Leaky Vessels : fuites de descripteurs de fichiers et de répertoire de travail atteignant le système de fichiers de l'hôte.
- CRI-O cr8escape : définir des paramètres noyau arbitraires sur l'hôte via une annotation de pod.
- containerd shim API : atteindre la socket de contrôle du shim pour exécuter des processus sur l'hôte.