Attaque Symlink-Exchange - runc - (CVE-2021-30465)
Mis à jour
Est-ce que cette infomation vous a été utile ?
Récapitulatif
Red Hat a pris connaissance d'une faille qui se trouve dans runc où un attaquant qui peut déployer un conteneur pourrait potentiellement s'échapper du conteneur et aller vers le système hôte. La seconde vulnérabilité est nommée CVE-2021-30465 et comporte un niveau de sévérité Important. Si SELinux est exécuté en mode d'exécution «enforcing», l'impact est réduit.
Les versions de produits Red Hat suivants sont affectées :
Red Hat Enterprise Linux 8
Red Hat OpenShift Container Platform 4.x
Red Hat Enterprise Linux 7
Red Hat OpenShift Container Platform 3.x
De plus, tout produit Red Hat pris en charge par la plateforme Red Hat Enterprise Linux est aussi potentiellement impacté. Ceci inclut les produits qui extraient des packages du canal RHEL. Veuillez vous assurer que le package Red Hat Enterprise Linux runc ou docker sous-jacent est à jour dans ces environnements de produits.
Pour déterminer si votre système est actuellement concerné par ces failles de sécurité, voir la section Diagnostic ci-dessous.
Résumé technique
Une vulnérabilité découverte dans runc permet de sortir du conteneur et d'accéder au système de fichiers de l'hôte.
Cette vulnérabilité affecte runc et tous les paquets d'outils de conteneurs qui en dépendent, disponibles sur Red Hat Enterprise Linux (RHEL) 8. OpenShift Container Platform (OCP) 4.x est également affecté car il utilise également runc via cri-o.
Cette vulnérabilité affecte les paquetages docker et runc disponibles sur Red Hat Enterprise Linux 7, qui sont livrés via le canal Extras. OpenShift Container Platform (OCP) 3.x dépend de ces paquets de Red Hat Enterprise Linux 7 Extras et est également affecté.
Mesures de mitigation
L'impact de la vulnérabilité est réduit si SELinux est en mode d'exécution «enforcing» en utilisant la stratégie container-selinux. La stratégie container-selinux est installée et activée par défaut sur RHEL 7 et 8, ainsi que sur OpenShift Container Platform 3.x et 4.x.
Il est fortement recommandé aux clients qui exécutent les versions concernées de RHEL d'appliquer les mises à jour RPM à partir du canal RHEL 8 et du canal RHEL 7 Extras dès que les errata sont disponibles.
Il est fortement recommandé aux clients utilisant les versions concernées d'OpenShift Container Platform de procéder à une mise à niveau dès que l'errata est disponible.
Les clients d'OpenShift Online ou OpenShift Dedicated ont SELinux activé en mode d’exécution «enforcing» dans chaque hôte dans tous les clusters. Par conséquent, on s'attend à ce que l'impact de ce problème sur les OSO/OSD soit réduit, les correctifs de sécurité étant disponibles lors des prochaines fenêtres de maintenance.
Détails techniques
Le paquet runc est vulnérable à une attaque par échange de liens symboliques par laquelle un attaquant peut demander une configuration de conteneur apparemment inoffensive qui entraîne le montage en liaison du système de fichiers hôte dans le conteneur.
Le paquet runc peut être utilisé de manière autonome pour exécuter des conteneurs, mais il est généralement utilisé par d'autres paquets pour exécuter des conteneurs. Sur RHEL 8, le paquet module container-tools, podman, utilise runc et est donc vulnérable via sa dépendance à runc. OCP 4 est vulnérable via le paquet cri-o, qui utilise runc. Sur RHEL-7, le paquet docker intègre runc et est vulnérable à ce problème. OCP 3 utilise le paquet docker dans sa configuration par défaut et est également affecté. OCP 3 peut être configuré pour utiliser cri-o au lieu de docker, et dans ce cas, est également affecté.
Dans le cas où un conteneur est en cours de démarrage et que runc effectue un montage à l'intérieur d'un volume partagé avec un autre conteneur (qui mène une attaque par échange de liens symboliques), runc peut être amené à effectuer un montage en dehors du système de fichiers racine du conteneur en échangeant la cible d'un montage (mount) avec un lien symbolique en raison d'une faille de type TOCTTOU (time-of-check-to-time-of-use).
Cependant, cela n'est pas utile car cela se produit à l'intérieur d'un espace de nom de montage avec une propagation "MS_SLAVE" appliquée à "/" (ce qui signifie que le montage n'apparaît pas sur l'hôte -- c'est seulement un "mount côté hôte" à l'intérieur de l'espace de nom du conteneur). Pour exploiter cela, vous devez avoir des entrées de mountage (mount) supplémentaires dans la configuration qui utilisent un sous-chemin du chemin de l'hôte monté comme source pour un montage ultérieur.
Impact sur les produits
OpenShift Container Platform
Dans le cas d'OpenShift Container Platform, ce problème est exploitable en créant un lien symbolique dans un volume vers le répertoire de premier niveau (bien connu) d'où proviennent les volumes (par exemple, "/var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir"), puis en utilisant ce lien symbolique comme cible d'un montage.
La source du montage est un répertoire contrôlé par un attaquant, et donc le répertoire source à partir duquel les montages suivants se produiront est un répertoire contrôlé par un attaquant. L'attaquant peut d'abord placer un lien symbolique vers "/" dans son répertoire source malveillant avec le nom d'un volume, et un montage ultérieur dans le conteneur montera "/" dans le conteneur.
L'impact de la vulnérabilité est réduit si SELinux est en mode d'exécution «enforcing» en utilisant la stratégie container-selinux. La stratégie container-selinux est installée et activée par défaut sur OpenShift Container Platform 3.x et 4.x.
Impact des services
OpenShift Online/Dedicated (OSD)
Dans OpenShift Dedicated (OSD), chaque client dispose d'un ou plusieurs clusters dédiés et ne partage pas ces clusters. Par conséquent, l'exposition est limitée à ce seul client.
Les clients d'OpenShift Online et OpenShift Dedicated ont activé SELinux en mode d’exécution «enforcing» dans chaque hôte de tous les clusters, ce qui réduit l'impact (plus de détails dans la FAQ ci-dessous).
Cette vulnérabilité ne peut être exploitée que si un attaquant est capable de déployer un conteneur. Le déploiement de conteneurs dans OSD n'est possible que pour les utilisateurs authentifiés et autorisés. Red Hat recommande de ne déployer que des conteneurs de confiance (par exemple, vérifier qu'ils proviennent d'une source de confiance, Health Index Okay [6])
Red Hat Developer Sandbox
Le paquetage vulnérable est présent dans le Red Hat Developer Sandbox en tant que dépendance transitive d'un autre paquetage. Il n'est ni utilisé ni nécessaire, et le service n'est pas affecté. Dans tous les cas, lors d'une prochaine fenêtre de maintenance, le paquet sera retiré.
Red Hat OpenShift API Management
Le paquetage vulnérable est présent dans la base de code de Red Hat OpenShift API Management. Seuls les administrateurs du service géré peuvent déployer des conteneurs, qui sont vérifiés et approuvés avant le déploiement. Le service n'a pas été affecté et le risque est faible. Dans tous les cas, lors d'une prochaine fenêtre de maintenance, le paquet compromis sera mis à jour.
Mises à jour des produits concernés
Nous conseillons à tous les clients de Red Hat exécutant des versions de produits Red Hat affectés de procéder aux mises à jour dès que les correctifs sont disponibles. Les clients sont invités à appliquer immédiatement les mises à jour disponibles et à activer les mesures de mitigation de l’impact qu'ils jugent appropriées.
Produit | Variante | Composante(s) | Alerte / Mise à jour |
OpenShift Enterprise 3 | 3.11 | runc | [1] |
OpenShift Enterprise 3 | 3.11 | docker | [1] |
OpenShift 4 | 4.7 | runc | [1] |
OpenShift 4 | 4.6 | runc | [1] |
OpenShift 4 | 4.5 | runc | [1] |
Red Hat Enterprise Linux 7 | runc | [1] | |
Red Hat Enterprise Linux 7 | docker | [1] | |
Red Hat Enterprise Linux 8 | z-stream | container-tools:1.0/runc | [1] |
Red Hat Enterprise Linux 8 | z-stream | container-tools:rhel8/runc | [1] |
Red Hat Enterprise Linux 8 | z-stream | container-tools:2.0/runc | [1] |
Red Hat Enterprise Linux 8 | z-stream | container-tools:3.0/runc | [1] |
[1] Le lien "Avis/Mise à jour" sera ajouté une fois que les mises à jour seront mises en ligne.
[2] Qu'est-ce que l'abonnement à Red Hat Enterprise Linux Extended Update Support (EUS) ?
[3] Qu'est-ce que l'Advanced mission critical Update Support (AUS) ?
[4] Qu'est-ce que l'abonnement à Red Hat Enterprise Linux SAP Solutions ?
[5] L'accès à ce patch nécessite un abonnement actif à Extended Life-cycle Support (ELS). Veuillez contacter le service commercial de Red Hat ou votre représentant commercial spécifique pour plus d'informations si votre compte n'a pas d'abonnement ELS actif.
[6] Les conteneurs de produits qui utilisent l'image de base de Red Hat Enterprise Linux. Les images de base seront mises à jour pour inclure les corrections de cette vulnérabilités, veuillez vous assurer que les conteneurs sont à jour. L'index de santé des conteneurs (Container Health Index), qui fait partie du Red Hat Container Catalog, peut toujours être utilisé pour vérifier le statut de sécurité des conteneurs Red Hat.
[7] Les produits qui extraient des packages du canal RHEL. Veuillez vous assurer que le package Red Hat Enterprise Linux sous-jacent est à jour dans ces environnements de produits.
Diagnostic
Un script de détection a été développé afin de déterminer si votre système est actuellement concerné par cette faille de sécurité. Pour vérifier la légitimité du script, vous pouvez télécharger la signature GPG détachée également. Les instructions sur la manière d'utiliser la signature GPG pour la vérification sont disponibles sur le Portail client.
FAQ
Q : SELinux atténue-t-il cette vulnérabilité ?
R : Bien qu'il soit toujours possible d'exploiter la vulnérabilité lorsque SELinux est en mode d'exécution «enforcing», l'impact de la vulnérabilité est réduit. Un attaquant devrait avoir monté le système de fichiers hôte dans un processus de conteneur avec un libellé SELinux. SELinux vous empêche d'accéder aux fichiers ou aux sockets qui ne sont pas autorisés par votre libellé. Il est toujours possible d'exploiter la vulnérabilité pour avoir un impact sur la confidentialité, l'intégrité ou la disponibilité du système d'exploitation hôte.
Q : Quelle est la probabilité que cette vulnérabilité soit exploitée ?
R : Si vous autorisez des utilisateurs non fiables à exécuter des conteneurs dans votre environnement ou si vous autorisez des utilisateurs fiables à déployer des conteneurs non fiables dans votre environnement, vous êtes plus susceptible d'être affecté par ce problème.
Remerciements
Red Hat remercie l'équipe de sécurité Open Containers en amont pour avoir signalé ce problème. L’équipe de sécurité en amont reconnaît la contribution d’ Etienne Champetier, le chercheur qui a découvert cette faille.
Comments