Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre éprouvé
    Avatar de emixam16
    Homme Profil pro
    Doctorant en sécurité
    Inscrit en
    juin 2013
    Messages
    244
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : Doctorant en sécurité

    Informations forums :
    Inscription : juin 2013
    Messages : 244
    Points : 1 247
    Points
    1 247
    Par défaut 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é".

    Nom : linux-container-runc-docker-hack.png
Affichages : 5370
Taille : 18,4 Ko

    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 ?

    Qu'en pensez-vous ?
    Utilisez-vous des conteneurs ?
    Êtes-vous vulnérable à cette faille ?
    Pensez-vous qu'une telle faille pourrait générer une apocalypse numérique ?

  2. #2
    Membre chevronné

    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2013
    Messages
    693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2013
    Messages : 693
    Points : 1 773
    Points
    1 773
    Par défaut
    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 ?
    Consultez mes articles sur l'accessibilité numérique :

    Comment rendre son application SWING accessible aux non voyants
    Créer des applications web accessibles à tous

    YES WE CAN BLANCHE !!!

    Rappelez-vous que Google est le plus grand aveugle d'Internet...
    Plus c'est accessible pour nous, plus c'est accessible pour lui,
    et meilleur sera votre score de référencement !

  3. #3
    Membre éprouvé
    Avatar de emixam16
    Homme Profil pro
    Doctorant en sécurité
    Inscrit en
    juin 2013
    Messages
    244
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : Doctorant en sécurité

    Informations forums :
    Inscription : juin 2013
    Messages : 244
    Points : 1 247
    Points
    1 247
    Par défaut
    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 :
    Critères de Popek et Goldberg
    Excellent livre : Hardware and Software Support for Virtualization
    Site de Drakvuf

  4. #4
    Membre chevronné

    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2013
    Messages
    693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2013
    Messages : 693
    Points : 1 773
    Points
    1 773
    Par défaut
    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.
    Consultez mes articles sur l'accessibilité numérique :

    Comment rendre son application SWING accessible aux non voyants
    Créer des applications web accessibles à tous

    YES WE CAN BLANCHE !!!

    Rappelez-vous que Google est le plus grand aveugle d'Internet...
    Plus c'est accessible pour nous, plus c'est accessible pour lui,
    et meilleur sera votre score de référencement !

  5. #5
    Membre éprouvé
    Avatar de emixam16
    Homme Profil pro
    Doctorant en sécurité
    Inscrit en
    juin 2013
    Messages
    244
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : Doctorant en sécurité

    Informations forums :
    Inscription : juin 2013
    Messages : 244
    Points : 1 247
    Points
    1 247
    Par défaut
    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.

    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.

    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)

Discussions similaires

  1. Réponses: 24
    Dernier message: 02/03/2019, 13h06
  2. Réponses: 1
    Dernier message: 08/05/2017, 14h48
  3. Réponses: 2
    Dernier message: 17/12/2015, 12h53
  4. Réponses: 3
    Dernier message: 04/06/2014, 13h06
  5. Réponses: 9
    Dernier message: 22/11/2010, 14h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo