Faille conceptuelle majeure dans la virtualisation matérielle

Posté par . Modéré par Florent Zara.
Tags :
0
4
juil.
2006
Sécurité
Si vous suivez un peu l'actualité de la sécurité informatique, vous vous souvenez probablement de SubVirt, un prototype de rootkit utilisant des machines virtuelles logicielles (permettant de faire tourner par-dessus plusieurs SE simultanément) pour prendre le contrôle de l'ordinateur. Sachez qu'on a réussi pire.

Une chercheuse en sécurité informatique, Joanna Rutkowska, étudie un autre prototype, le sien : Blue Pill (en référence à la pilule bleue dans Matrix qui permet de ne plus se souvenir de rien et d'être de nouveau dans la réalité factice quoique plus vraisemblable que la réalité). Ce prototype-là peut être installé à la volée. Du coup, pas de redémarrage nécessaire, partant, pas de changement à faire dans le bootloader ou autre partie du disque dur, cette activité pouvant toujours être surveillée par un logiciel spécialisé contre les malwares.

Blue Pill a été testé sur la technologie Pacifica de virtualisation matérielle d'AMD. Faute de temps aucun test n'a encore été effectué sur la technologie concurrente Intel VT. Mais Joanna pense que Blue Pill fonctionnera très probablement aussi avec cette technologie. Elle pense qu'il est possible de contrer des rootkits basés sur Blue Pill. Grâce à ses prochaines démonstrations sur SyScan et Black Hat. On y trouvera sûrement, on l'espère, la parade.

Joanna Rutkowska s'est notamment illustrée avec Red Pill ou klister, des logiciels de détection de rootkits plus classiques. Ses recherches sont actuellement financées par COSEINC Research… Clairement, pour les pirates de tous poils, l'avenir est aux rootkits. Ils ont fait leurs preuves pour contrôler l'utilisateur parce qu'ils se logent dans les couches les plus inaccessibles du système, et parce que d'après Blue Pill, ils ont beaucoup de potentiel.

La meilleure preuve de cela étant que les grandes firmes elles-même se tournent vers ce type de solutions pour leurs basses ½uvres (cf l'affaire du rootkit de Siny pour la plus célèbre.).

Les linuxiens, avec ces rootkits nouvelles générations sont aussi concernés, vu que ce sont des malwares de moins en moins dépendants du système d'exploitation.

Comme cette faille de très bas niveaux semble ici bien involontaire, on n'atteindra pas le sommet de la manipulation du consommateur que représente potentiellement TCPA/Palladium. Les fondeurs se chargeront de trouver une solution digne de ce nom avant la démocratisation de ces technologies. Pas d'inquiétude particulière à priori, donc.

Aller plus loin

  • # Avec XEN

    Posté par . Évalué à 6.

    Une question que je me pose, est qu'avec un XEN en dom0, ce rootkit pourrai "cohabiter" ? ou est ce que la presence de XEN dans le ring 0 empecherait l'éxecution de ce rootkit ? (enfin je sais pas si j'ai été trés clair :D )
    • [^] # Re: Avec XEN

      Posté par . Évalué à -3.

      enfin je sais pas si j'ai été trés clair
      Non
    • [^] # Re: Avec XEN

      Posté par (page perso) . Évalué à 6.

      >> Une question que je me pose, est qu'avec un XEN en dom0, ce rootkit pourrai "cohabiter" ? ou est ce que la presence de XEN dans le ring 0 empecherait l'éxecution de ce rootkit ?

      Tu le saura bientôt :


      Should future OS come with own, preinstalled hypervisor to prevent Blue Pill installation? What about timing analysis? All those questions will be answered during my presentation - please do not send or post the same questions again and again...


      Mon pari (basé sur rien d'autre que le pifomètre) est que xen ne tolérera pas un autre hyperviseur en même temps que lui.
      • [^] # Re: Avec XEN

        Posté par (page perso) . Évalué à 3.

        Mon pari (puisque les paris sont gratuit aujourd'hui) est que "Vista Server" aura un hyperviseur intégré qui ne tolèrera pas un autre.

        Si Microsoft est sympa, cet hyperviseur ne verra que les Vista ;-) S'il est encore plus sympa, Vista Server ne tournera que dans leur hyperviseur...

        Bon ok -> []
  • # Doute ?

    Posté par . Évalué à 4.

    D'après l'article sur son blog, elle pose la question : est-ce que l'OS doit fonctionner dans une VM ?

    Dans un des commentaires :

    On AMD64, any attempt to enable hardware virtualization inside a virtualized session will trap out to the top level hypervisor. The current implementation of Pacifica isn't capable of nesting VMs natively.


    Donc si je comprends bien, si l'OS s'installe dès le début dans une VM, le problème est réglé : lorsque la pillule bleue voudra faire son tour de passe passe, elle sera bloquée par l'OS (le "top level hypervisor" que je suppose être le code gérant les VM).

    Donc il "suffit" que les OS soit mis à jour et le problème est réglé (sachant qu'il n'y a pas de perte de performance d'après son blog).

    J'ai pas lu les spéc de Pacifica, donc j'ai peut être loupé quelque chose ?

    (Ca me rappel EMM386 qui faisait tourner le DOS en mode protégé VM86 pour faire des switch de page RAM rapidement)
  • # incomprehensible

    Posté par . Évalué à 10.

    Je sais que cet article est destiné à des personnes ayant un minimum de connaissances dans le domaine, mais pour un article de premiere page, je trouve que ca reste vraiment incomprehensible.

    Si quelqu'un pouvait me (et à d'autres) expliquer un peu plus de quoi il en ressort, ce serait cool.

    Je tiens particulierement à etre eclairé sur ces phrases et notions :
    prototype de rootkit
    (je sais ce qu'est un prototype mais on sait jamais si ca peut avoir un autre sens dans le domaine de la suce)

    cette activité pouvant toujours être surveillée par un logiciel spécialisé contre les malwares.
    je ne suis pas sur de bien saisir de quelle activitée on parle.

    Ces phrases et notions peuvent peut etre etre comprise avec un peu de reflexion.

    Par contre ce que je ne saisis vraiment pas, c'est comment il opere en tant que rootkit : il s'installe comme un os supplementaire a coté des autres os qui tournent dans leur vm ? Il peut compromettre les os qui tournent dans leur vm ou alors sa seule visibilité est sa vm, et donc il ne sert a rien ?

    Voila, en ecrivant ce commentaire je comprend un peu mieux mais j'aurais preferé ne pas avoir eu a le faire :]
    et puis ca aidera peut etre d'autres a comprendre.
    • [^] # Re: incomprehensible

      Posté par (page perso) . Évalué à 10.

      Alors en fait "Blue Pill" est un prototype de rootkit en ce sens que ne faisant rien de mal et etant un projet de travail ce n'est pas au sens premier un rootkit mais fourni une base pour une implementation d'un rootkit performant multi-os et absolument invisible.

      Quand a son fonctionnement il est basé sur les technologies de virtualisation matérielles. Schematiquement une fois executé sur un
      OS 'standard' ne gerant pas les extensions pacifica/VT il va s'installer en tant qu'hyperviseur, sorte de superviseur de système d'exploitation
      chargé de gerer l'acces aux ressources materielles.


      cette activité pouvant toujours être surveillée par un logiciel spécialisé contre les malwares.
      je ne suis pas sur de bien saisir de quelle activitée on parle.

      Je ne comprend pas ton problème, le debut de la phrase explique que les precedents rootkit s'installant en hyperviseur necessitaient une execution precedent le lancement du systeme d'exploitation et partant de la une écriture sur le disque dur notamment dans les secteurs de démarrage. C'est de cela dont il est question (l'ecriture disque).


      Quand aux risques et bien ils sont maximum, le fonctionnement du mode hyperviseur permettant meme d'ecrire sur le kernel du systeme d'exploitation devenu invité.
    • [^] # Re: incomprehensible

      Posté par . Évalué à 10.

      Ce que j'en comprends (à corriger si besoin) :

      - Pacifica (Secure Virtual Machine) : c'est un ensemble d'instructions assembleurs pour les processeurs AMD (les nouveaux). Le but est d'aider les logiciels comme QEmu, VMWare avec l'aide ces instructions (exemple : faire fonctionne Windows dans Linux sur un AMD). Donc en gros, le système d'exploitation est chapoté par une sorte de meta OS. C'est un "peu" comme la fenêtre DOS (en mode réel) qu'il y avait avec Windows 95 (en mode protégé) : le DOS a l'impression d'être tout seul mais Windows peut contrôler chacunes de ses actions. La un pas de plus en franchi.

      - Les malwares : actuellement, un bout de logiciel peut installé un meta OS (le "top level hypervisor"), et basculer Windows Vista dans une machine virtuelle. Donc l'OS fonctionne mais ne pourra jamais avoir accès au meta OS qui est géré par le malware. Donc les logiciels de détection de malware peuvent bien connaître l'astuce, ce n'est pas détectable : le processeur cache ce meta OS (un peu comme le DOS qui ne pouvait pas "voir" Windows). Et d'après son blog, il n'y a pas de perte de performance.

      (ma comparaison avec Windows95/DOS est peut être tiré par les cheveux).
      • [^] # Re: incomprehensible

        Posté par . Évalué à 10.

        En fait QEmu et VMWare proposent déjà ces services, c'est ce qu'on appelle un VMM (Virtual machine monitor) qui permet de faire tourner plusieurs VM sur un seul ordinateur.

        Actuellement cependant les logiciels en questions sont extrèmement complexes et lourds parce que les CPUs ne sont pas ce qu'on appelle "virtualisables", autrement dit lorsqu'une application en mode non privilégié essaie d'exécuter une instruction du mode privilégié (on parle d'instruction CPU ici), un CPU virtualisable devrait lancer une interruption et laisser le VMM traiter le problème.
        Or l'architecture x86 ne fait pas cela (elle a un comportement incohérent selon les instructions, soit elle les ignore, soit elle fait planter le programme fautif...), elle n'est donc pas adapté à la virtualisation directe du CPU (où le VMM se contenterais d'exécuter les OS résident en mode non-privilégié et de traiter les interruptions).
        Pacifica ou Vanderpool devrait entre autre permettre de rajouter un mode d'exécution virtualisable à x86. (je crois qu'il y a d'autres points à considérer (comme la gestion de la mémoire : avoir plusieurs MPU matérielles serait utile par exemple) mais je ne suis pas spécialiste). (Pour l'instant les VMMs transforme le code binaire des programmes pour qu'ils exécutent des instructions différentes lorsqu'ils devraient exécuter des instructions privilégiées, mais cela a un coût)

        --
        Jedaï
        • [^] # Re: incomprehensible

          Posté par . Évalué à 1.


          lorsqu'une application en mode non privilégié essaie d'exécuter une instruction du mode privilégié (on parle d'instruction CPU ici), un CPU virtualisable devrait lancer une interruption et laisser le VMM traiter le problème.
          Or l'architecture x86 ne fait pas cela


          Pourtant, la doc IA-32 stipule :

          If one of these instructions is executed when the CPL is not 0, a general-protection exception (#GP) is generated


          Peut-être que par "x86" tu voulais dire "x86-64" (dont je n'ai pas lu la doc) ?
          • [^] # Re: incomprehensible

            Posté par . Évalué à 2.

            Non non, je parle bien ici du x86. Peut-être aurai-je dû employer un vocabulaire différent : en fait les instructions du mode privilégié provoque bien une exception si elles sont employées en mode non privilégié, mais le problème est que l'ensemble de ces instructions ne recoupe pas l'ensemble des instructions qui modifie le comportement du processeur et qui ne peuvent être exécutée avec succès qu'en mode privilégié.
            Par exemple pour activer ou non les interruptions, il faut changer la valeur d'un registre du processeur, mais ce registre n'est évidemment (heureusement) pas accessible dans le mode non privilégié. Dans ce cas l'instruction elle-même est non privilégié (on peut l'utiliser légitimement en mode non privilégié), mais elle n'a aucun effet lorsqu'utilisée avec ce registre dans le mode non privilégié, et elle ne déclenche pas d'exception dans ce cas...
            (tu penses bien que les VM comme Xen seraient beaucoup plus performantes sinon.)

            --
            Jedaï
      • [^] # Re: incomprehensible

        Posté par . Évalué à 1.

        Ok,

        c'est tout de suite moins complexe avec vos explications a tout les deux :]

        donc en gros, ya un os qui tourne seul, comme n'importe quel os sur n'importe quel pross, sur un pross genre pacifica.
        la ya bluepill qui sramene, prend les droits hyperviseur, met l'os dans une vm, et est mettre complet de la machine.

        En meme temps quelle idee de mettre un os unique sans hiperviseur sur une machine faite pour en abriter 15 avec yperviseur ?
    • [^] # Re: incomprehensible

      Posté par . Évalué à 10.

      ca peut avoir un autre sens dans le domaine de la suce)


      Un autre sens ? Je n'en vois vraiment aucun ;)

      BeOS le faisait il y a 20 ans !

      • [^] # Re: incomprehensible

        Posté par . Évalué à 3.

        hihi :]

        il fallait bien sur secu :>
      • [^] # Re: incomprehensible

        Posté par (page perso) . Évalué à 10.

        D'après ce que j'ai compris, la pillule bleue augmente les performances de la suce, ce qui me semble confirmé par les nombreux courriers électroniques que je reçois.
    • [^] # Re: incomprehensible

      Posté par (page perso) . Évalué à 3.

      Il faut de tout pour faire un monde et ce genre de news un peu pointue me fait plaisir à voir sur linuxfr.

      Tu vois les commentaires sont là, aussi, pour rendre plus claire les news pas claires pour certains (ce qui est une bonne nouvelle linux n'est plus seullement utilisé par des grosses brutes en informatiques :) )
  • # Tempérer les effets d'annonce

    Posté par . Évalué à 10.

    Premièrement, une information qui n'est pas précisée dans cette nouvelle (à l'heure ou j'écris ce commentaire en tout cas) est que cet exploit n'est possible que sur les futures architectures x86 64 bits. Certe, ceux qui maîtrisent les technologies des processeurs ou qui ne sortent pas le dimanche auront compris cela à l'évocation du mot Pacifica (virtualisation AMD x64), mais pas tout le monde n'est expert en processeur.

    Deuxièmement, cet exploit n'aurait été implémenté à l'heure actuelle que sous Windows Vista Beta 2 sur un AMD64. La chercheuse précise tout de même pour les mauvaises langues que cet exploit n'est pas le fruit d'une faille de Windows Vista Beta 2. Elle ne verrait aussi aucune raison pour que ce ne soit pas possible sous Linux ou *BSD sur x64, mais de l'hypothèse à l'implémentation, aussi compétente soit-elle, ça laisse une marge. Déjà, comparé à la nouvelle publié ici, c'est déjà beaucoup plus nuancé.

    Troisièmement, et sans vouloir discréditer les dires de cette chercheuse, je pense qu'on saura ce que ses travaux valent réellement quand ils seront passés sous les mains expertes de ses confrères dont les critiques confirmeront la crédibilité de tout cela ... ou pas d'ailleurs.

    Donc bref, pas de quoi crier au loup ... pour l'instant.

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Tempérer les effets d'annonce

      Posté par (page perso) . Évalué à 4.

      Ben disons que c'est un problème principalement conceptuel
      La seule chose technique nécesaire qui n'est pas simple à faire et en quoi consiste blue pill, c'est de passer un OS de la machine physique à la VM.
      Bon sinon y a quand même quelques choses à noter pour effectivement tempérer cette annonce
      1.Le jeu d'instruction permettant la virtualisation n'est disponible à mon avis qu'au ring 0, c'est à dire que seul le kernel n'y a accès
      2.Il faut donc un accès root, ou du moins une méthode pouvoir charger un module, ou pour modifier.
      3.Blue Pill ne marche qu'exclusivement si aucun superviseur n'est déjà préchargé (sauf faille de secu dans le CPU ou le superviseur), donc vista beta2 y est sensible, mais il est probable que MS fasse un mini superviseur pour un seul OS qui est le sien qui permette tout, ca change rien pour l'OS et cette faille n'existe plus
      Au pire tu mets un xen pour éviter ce problème et basta :)
      Bon sinon j'aimerais bien avoir sous le coude un de ces CPU, avec des drivers NVIDIA qui gèrent la virtualisation (il parait que NVIDIA en a fait une démonstration)
      • [^] # Re: Tempérer les effets d'annonce

        Posté par (page perso) . Évalué à 3.

        1.Le jeu d'instruction permettant la virtualisation n'est disponible à mon avis qu'au ring 0, c'est à dire que seul le kernel n'y a accès
        2.Il faut donc un accès root, ou du moins une méthode pouvoir charger un module, ou pour modifier.
        C'est un peu un principe des rootkits. Le but n'est pas de gagner des privilèges (c'est à ça que servent les failles/exploits) mais de les garder discrètement.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Tempérer les effets d'annonce

          Posté par . Évalué à 1.

          non le but est de contourner les protections d'écriture de la mémoire du noyau ainsi que la vérifications des signatures des modules chargés afin de justement pouvoir rootkiter le dit noyau.
          • [^] # Re: Tempérer les effets d'annonce

            Posté par . Évalué à 2.

            Il me semble que Krunsh parlait ici du but du rootkit. Et dans ce cas, sa phrase est tout à fait pertinente. On installe un rootkit lorsque l'on a déjà aqui des privilèges superuser (la plupart du temps) via l'exploitation d'une faille.
    • [^] # Re: Tempérer les effets d'annonce

      Posté par . Évalué à 7.

      Tu as raison de tempérer les effets d'annonces. Concernant les processeurs, en effet les processeurs disposant de Pacifica ne semblent pas à l'heure actuelle très répandus.

      Toutefois, au delà du proof-of-concept Blue Pill :

      Faute de temps aucun test n'a encore été effectué sur la technologie concurrente Intel VT. Mais Joanna pense que Blue Pill fonctionnera très probablement aussi avec cette technologie.


      Il y a beaucoup plus de processeurs en circulation disposant d'IntelVT (a.k.a. Vanderpool), voir la liste sur le wiki de Xen http://wiki.xensource.com/xenwiki/IntelVT?highlight=%28Intel(...)

      Le point intéressant : sur le processeur dont je dispose (un Core Duo T2400) Vanderpool/IntelVT est désactivé dans le BIOS par défaut ! Donc pas vraiment de risque pour Monsieur Tout-le-monde. J'ignore ce qu'il en est chez les Pentium-4/D et autres futurs Core 2 Duo.

      Troisièmement, et sans vouloir discréditer les dires de cette chercheuse, je pense qu'on saura ce que ses travaux valent réellement quand ils seront passés sous les mains expertes de ses confrères dont les critiques confirmeront la crédibilité de tout cela... ou pas d'ailleurs.


      Tout à fait. Néanmoins Joanna Rutkowska reste quelqu'un dont les travaux sont intéressants. C'est loin d'être une inconnue, pour t'en convaincre tu peux parcourir la liste de ses articles publiés sur http://rootkit.com/user.php?name=joanna
    • [^] # Re: Tempérer les effets d'annonce

      Posté par . Évalué à 2.

      Mouais.
      Il me semble au vu du titre et du reste de la dépêche, qu'il est clair que seul les futures technologies d'AMD et d'Intel sont concernés par Blue Pill. Ce n'était peut-être pas très précis, mais j'avais pris soin de mettre des liens, quand même. On ne peut pas trop alourdir la dépêche. Ma dépêche n'est pas verbeuse, mais pas incomplète non plus. Elle est concise.

      Pour le reste, et surtout pour Donc bref, pas de quoi crier au loup ... pour l'instant.

      Je te rappelle la dernière phrase de ma dépêche (il ne faut pas oublier qu'il y a deux parties) : Les fondeurs se chargeront de trouver une solution digne de ce nom avant la démocratisation de ces technologies. Pas d'inquiétude particulière à priori, donc.

      Tu chipotes beaucoup alors que tu sembles surtout avoir lu certains passage en diagonale… ;¬)
  • # relations entre TCPA et logiciels indésirables ?

    Posté par . Évalué à 4.

    TCPA ne permettrait-il pas d'éviter l'installation d'hyperviseurs arbitraires, dès lors que le matériel en est correctement équipé et que la mise à la clé du hard est faite dans de bonnes conditions
    • [^] # Re: relations entre TCPA et logiciels indésirables ?

      Posté par . Évalué à 4.

      Oui et non. Si tu parles d'hyperviseurs tiers, oui, il empêchera leur installation «protégeant» ta machine.

      En revanche, si tu veux installer ton propre hyperviseur, parce que tu n'a pas confiance dans celui d'Intel ou Microsoft, tu peux rêver.

      C'est dans ce dernier sens que je faisais un parallèle avec TCPA : on n'en est pas encore au niveau d'une porte dérobée volontaire pour contrôler l'utilisateur, donc Blue Pill, quoiqu'inquiétante, n'a pas à provoquer de peurs particulières. C'était une dépêche avant tout informative, plutôt que préventive ou je ne sais quoi.

      TCPA, c'est échanger sa liberté contre sa sécurité. Une fois que tu ne seras plus libre, comment feras-tu si tu es déçu(e) par la sécurité ? Tu venais juste de tomber, mentalement, dans le piège que te tendent Microsoft et Intel…
      • [^] # Hein ? Quel vélo

        Posté par . Évalué à 1.

        Ouaips, enfin, bon, il reste toujours possible d'acheter d'autres procs, hein.... : pas d'hyperviseur, pas de TCPA, peu de problèmes (pratiques) de sécu de surcroit et pis basta... Quand on tient absolument à la "liberté d'emplyer Windows", faut assumer le petit sentiment de so****e qui va avec.
        • [^] # Re: Hein ? Quel vélo

          Posté par . Évalué à 3.

          Bof. On ne peut pas toujours se laisser faire larguer par l'évolution informatique. Parfois on a très envie voire besoin d'une nouvelle technologie…

          S'il n'y avait d'autres intérêts que des problèmes, particulièrement de sécurité, les firmes n'investiraient pas autant…
    • [^] # Re: relations entre TCPA et logiciels indésirables ?

      Posté par . Évalué à 3.

      AHMA: pour installer un hyperviseurs/VMM, il faut être en mode protégé (le mode de linux, windows, mac intel, tous(?) sauf [Free]DOS), et il faut que ce code soit validé par le BIOS avant (validé au sens certificat tout ça).
      Donc ca ne change pas grand chose, si le code validé gère Pacifica/VT, le "problème" est réglé.

      Après on envisager une coopération TCPA / Virtualisation, mais comme la virtualisation est faite dans le CPU, et TCPA est géré par une puce à part, ce me semble difficile.
  • # Les VM et les failles de X

    Posté par . Évalué à 3.

    Il y a 2 mois, une news indiquait un problème de sécurité avec x.org ( http://linuxfr.org/2006/05/15/20813.html )

    Je me demande si il n'y aurait pas moyen de se protéger de ses attaques justement en faisant tourner linux/*bsd dans une VM ?

    L'article de Loïc Duflot indique 2 méthodes pour : par SMM ou par reprogrammation de l'ouverture graphique. Les 2 méthodes passent par des accès IO que le superviseur pourait intercepter.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.