Une faille critique dans RunC permet une évasion des conteneurs Linux pour gagner un accès root sur l'hôte

Version imprimable

12/02/2019, 12h05
emixam16

1 pièce(s) jointe(s)

Une faille critique dans RunC permet une évasion des conteneurs Linux pour gagner un accès root sur l'hôte

Une vulnérabilité critique affectant RunC a été révélée aujourd'hui. RunC constitue la brique de base des systèmes de conteneurisation et permet de lancer et d'exécuter des conteneurs. RunC est utilisé par les systèmes de conteneurisation les plus courants comme Docker ou Kubernetes.

Pour rappel, la conteneurisation est une technique de virtualisation légère permettant de lancer des "conteneurs" isolés entre eux qui peuvent s'apparenter à des machines réelles. La sécurité de ces conteneurs peut être gérée finement depuis l'hôte. Un conteneur est généralement plus léger et plus rapide à l'exécution qu'une machine réelle. Pour cette raison, ces systèmes sont très massivement utilisés, notamment dans le Cloud.

Techniquement, en créant un conteneur malicieux un attaquant est en mesure d'exploiter une mauvaise gestion des descripteurs de fichiers et de réécrire arbitrairement le binaire de RunC. Cela permet de récupérer un contrôle total (administrateur) sur la machine et sur les autres conteneurs éventuellement exécutés sur celle-ci.

D'après Scott McCarty, Product Manager chez Red Hat, "Si peu de scénarios pourraient engendrer une apocalypse pour une entreprise de l'IT, une cascade d'attaques affectant un large éventail de systèmes de production interconnectés en fait clairement partie... Et c'est exactement ce que représente cette vulnérabilité".

Pièce jointe 449360

Si la plupart des systèmes Linux sont vulnérables à cette faille, les distributions ayant SELinux activé (enforcé) mitigent cette faille. C'est notamment le cas de Red Hat ou Fedora. Au contraire, des distributions comme Debian ou Ubuntu ont publiquement annoncé être vulnérables à cette faille critique.

Si vous utilisez des conteneurs en production, vous êtes probablement vulnérable à cette attaque, il est important de mettre à jour votre logiciel de conteneurisation dès qu'un patch sortira pour le vôtre.

Source : Lien vers la faille, Red Hat

Et vous ?

:fleche: Qu'en pensez-vous ?
:fleche: Utilisez-vous des conteneurs ?
:fleche: Êtes-vous vulnérable à cette faille ?
:fleche: Pensez-vous qu'une telle faille pourrait générer une apocalypse numérique ?
18/02/2019, 17h11
CoderInTheDark

Quand on est dans un conteneur, on est comme le mime Marceau sans sa boîte invisible.
Dans ce type d'attaque on sait qu'on est dans un conteneur

Mais je me demandais, si une application à le moyen de détetecter si elle est sur une vraie machine ou un conteneur ?
22/02/2019, 11h40
emixam16

A l'origine de la virtualisation, les critères retenus pour une virtualisation efficaces ont étés définis comme:
- Efficacité (overhead négligeable)
- Sécurité (Le VMM a le contrôle sur les ressources)
- Équivalence (programme virtualisé indistinguable d'un programme Natif)}

Ces critères, introduits par Popek et Goldberg en 1971 sont toujours d'actualité.

Dans l'idéal un conteneur ne devrait donc pas être en mesure de détecter qu'il en est un.

Mais malheureusement, un prérequis de ce théorème (toutes les instructions sensibles sont privilégiées) n'est pas respecté dans les principales architectures actuelles (x86, ARM, ...). Ces architectures ne sont donc pas visualisables selon ces principes.

Donc une virtualisation basé sur des principes plus faibles est actuellement utilisée. Et globalement c'est le principe d'équivalence qui a été sacrifié. (C'est un peu moins le cas aujourd'hui avec le nouveau matériel/les nouvelles instructions dédiés à la virtualisation comme Intel VT-X mais je simplifie).

Ainsi, il est possible de détecter qu'on est sur une plateforme virtualisée soit parce que ce n'est pas caché (ex: hyperviseur) soit en testant des comportement sur des cas précis. Par exemple, l'outil systemd-detect-virt permet de détecter la virtualisation et même le nom de l'hyperviseur.

Toutefois, il existe des frameworks comme Drakvuf spécifiquement conçus pour cacher qu'ils virtualisent la plateforme (par exemple pour de l'analyse de malware, ces derniers ayant la fâcheuse tendance à se désactiver si il détectent être sur une machine virtuelle).

Donc globalement une VM peut détecter qu'elle est une VM sauf si on cherche spécifiquement à le lui cacher (généralement au détriment de la performance).

Bonne journée.

Plus d'infos :
:fleche: Critères de Popek et Goldberg
:fleche: Excellent livre : Hardware and Software Support for Virtualization
:fleche: Site de Drakvuf
22/02/2019, 17h35
CoderInTheDark

Donc un attaquant pourrait louer une VM pour attaquer un cloud entier ?
Car si il remonte sur l'hyperviseur, il à la main sur toutes les vm et potentiellement peut accéder aux autre hyperviseurs ?
Les hyperviseurs sont ils isolé les uns des autres, ou peuvent ils être coupé en cas de comportement suspect ?

Quand aux malware ils savaient déjà détecter qu'ils étaient dans un bac à sable, et qu'ils étaient potentiellement tester par un antivirus.
Par exemple si il ne pouvaient pas accéder aux disques.
25/02/2019, 19h07
emixam16

Citation:

Donc un attaquant pourrait louer une VM pour attaquer un cloud entier ?
Car s'il remonte sur l'hyperviseur, il a la main sur toutes les vm et potentiellement peut accéder aux autres hyperviseurs ?

Très exactement. Cette faille permet de compromettre l'hôte donc d'avoir accès à toutes les entités virtualisées sur le même nœud.

Elle permet donc d'avoir un accès root à l'intérieur de la DMZ ce qui facilite considérablement l'attaque des autre nœuds du réseau (par exemple en demandant simplement un transfert de la VM malicieuse vers un autre nœud).

Au final on peut "facilement" attaquer toute l'infrastructure de l'entreprise. C'est pour ça que ce type de faille est tant craint par les experts.

Citation:

Les hyperviseurs sont ils isolés les uns des autres, ou peuvent ils être coupés en cas de comportement suspect ?

Cela dépend des politiques de l'entreprise, par défaut non mais des protections supplémentaires peuvent être mises en place pour gérer ce type de problème (ex: SELinux (MAC + RBAC), IMA (vérification d'intégrité) ...). Mais pour une majorité d'entreprises ces dispositions ne sont pas (ou mal ou pas suffisamment) prises.

Citation:

Quand aux malware ils savaient déjà détecter qu'ils étaient dans un bac à sable, et qu'ils étaient potentiellement tester par un antivirus.
Par exemple si il ne pouvaient pas accéder aux disques.

Oui, comme je te l'ai dit dans mon précédent post. Un Malware sait quand il est virtualisé (il a alors tout intérêt de se désactiver pour ne pas être reverse-enginéré). On peut essayer de lui cacher qu'il est virtualisé (cf. Drakvuf)