Remarque perev. : Hier soir, Aleksa Sarai, un ingénieur conteneur senior chez SUSE Linux, a déclaré à la liste de diffusion oss-sec une vulnérabilité de sécurité runc / LXC critique qui pourrait permettre à un attaquant ayant accès à un conteneur isolé d'obtenir des privilèges root sur le système hôte. Étant donné que le problème a été identifié dans l'implémentation de référence du runtime de conteneur - runc - il affecte de nombreux systèmes de conteneur, dont Docker / Moby, Podman , cri-o (et Kubernetes lui-même). Les détails sont présentés ci-dessous sous la forme de la traduction d'un message d'un ingénieur en une liste de diffusion.Je suis l'un des mainteneurs de runc (le runtime de conteneur sous-jacent utilisé par Docker, cri-o, containerd, Kubernetes, etc.). Récemment, nous avons découvert une vulnérabilité que nous avons vérifiée et corrigée.
Chercheurs qui ont découvert la vulnérabilité:
- Adam Iwaniuk;
- Borys Popławski.
De plus, Aleksa Sarai (c'est-à-dire I) a découvert que le LXC est également affecté par une version plus sophistiquée de cette vulnérabilité.
Brève revue
La vulnérabilité permet à un conteneur malveillant (avec une interaction utilisateur minimale) d'écraser le binaire de l'hôte runc et ainsi être en mesure d'exécuter du code avec des privilèges root sur l'hôte. Le degré d'interaction de l'utilisateur est tel qu'il vous permet d'exécuter n'importe quelle commande (peu importe si l'attaquant contrôle la commande) avec des privilèges root dans le conteneur dans l'un de ces contextes:
- Création d'un nouveau conteneur à partir d'une image contrôlée par un attaquant;
- Connexion (
docker exec ) à un conteneur existant auquel l'attaquant avait précédemment accès en écriture.
Cette vulnérabilité n'est
bloquée ni par la stratégie AppArmor par défaut ni par la stratégie par défaut SELinux dans Fedora * (car les processus de conteneur semblent avoir commencé avec
container_runtime_t ). Cependant, il est
bloqué par l' utilisation correcte des espaces de noms utilisateur (où la racine de l'hôte ne correspond pas à l'espace de noms utilisateur du conteneur).
Le vecteur CVSSv3 (avec une note de 7,2) est le suivant:
AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:HLe
problème est attribué
CVE-2019-5736 .
* Le problème s'applique uniquement au package moby-engine dans Fedora. Le package docker , comme podman , est protégé de son fonctionnement, car il démarre les processus de container_t tant que container_t .Patchs
0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch le correctif approprié pour résoudre le problème (
0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch ). Il est basé sur la branche
HEAD , bien que le code dans
libcontainer/nsenter/ change si rarement que le correctif s'applique très probablement à presque toutes les anciennes versions de la base de code runc que vous traitez.
Veuillez noter que le
patch que je pousse vers la branche master runc est une version modifiée de ce patch, bien qu'ils soient fonctionnellement identiques (si vous n'avez pas encore patché vos fichiers avec le patch attaché, nous vous recommandons d'utiliser la version en amont).
Code d'exploitation secondaire
Certains fournisseurs ont demandé un code d'exploitation pour s'assurer que les correctifs résolvaient le problème. Étant donné que le problème est très grave (en particulier pour les fournisseurs de cloud public), nous avons décidé de fournir un tel code. L'exploit que j'ai écrit est plus général que le code original fourni par les chercheurs et fonctionne pour LXC (il ne nécessite pas de modifications importantes pour pouvoir s'appliquer à d'autres environnements exécutables vulnérables). Les détails sur l'utilisation du code d'exploitation sont fournis dans le
README .
Conformément aux règles d'OpenWall, le code d'exploitation sera rendu
public 7 jours après la CRD (c'est-à-dire le 18 février 2019).
Si vous disposez d'un runtime de conteneur, assurez-vous qu'il n'est pas affecté par cette vulnérabilité.Impact sur d'autres projets
Il convient de noter que lors d'une enquête plus approfondie sur le problème, j'ai constaté que le LXC a une vulnérabilité similaire, et ils ont déjà poussé un
patch similaire
de notre développement conjoint. LXC est un peu plus difficile à utiliser, mais le problème lui-même est le même.
Une discussion avec des représentants de systemd-nspawn a conduit à la conclusion qu'ils ne sont pas vulnérables (car ils ont une méthode différente de connexion au conteneur pour LXC et runc).
Des représentants d'Apache Mesos m'ont également contacté, signalant qu'ils sont également vulnérables (je pense qu'ils ont simplement utilisé le code d'exploitation qui sera publié). Il est très probable que la plupart des durées d'exécution des conteneurs soient vulnérables si elles n'ont pas pris auparavant des mesures très inhabituelles pour atténuer leur impact potentiel.
Autres actualités
Nous avons configuré la distribution d'annonces pour les futures vulnérabilités de sécurité: le processus de la rejoindre est décrit
ici (il est basé sur la liste de diffusion Kubernetes security-announce). Veuillez vous joindre si vous distribuez des temps d'exécution pour les conteneurs qui dépendent de runc (ou d'autres projets OCI).
PS Du traducteur
Problème CVE-2019-5736 dans les trackers des distributions Linux populaires:
... et l'
article de blog Kubernetes (consultez la section «Que dois-je faire?»).