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
- blog de Joanna Rutkowska (29 clics)
- Annonce sur Clubic (8 clics)
- Site officiel de COSEINC Research (2 clics)
- Virtualisation matérielle d'AMD (5 clics)
- Virtualisation matérielle d'Intel (4 clics)
- Wikipedia à propos des rootkits (7 clics)
# Avec XEN
Posté par Fabien Engels . Évalué à 6.
[^] # Re: Avec XEN
Posté par dab . Évalué à -3.
Non
[^] # Re: Avec XEN
Posté par patrick_g (site web personnel) . Évalué à 6.
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 Sytoka Modon (site web personnel) . Évalué à 3.
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 _alex . Évalué à 4.
Dans un des commentaires :
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 Victor . Évalué à 10.
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 -=[ silmaril ]=- (site web personnel) . Évalué à 10.
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 _alex . Évalué à 10.
- 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 Chaddaï Fouché . Évalué à 10.
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 pini . Évalué à 1.
Pourtant, la doc IA-32 stipule :
Peut-être que par "x86" tu voulais dire "x86-64" (dont je n'ai pas lu la doc) ?
[^] # Re: incomprehensible
Posté par Chaddaï Fouché . Évalué à 2.
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 Victor . Évalué à 1.
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 Pascal Terjan (site web personnel) . Évalué à 3.
[^] # Re: incomprehensible
Posté par dinomasque . Évalué à 10.
Un autre sens ? Je n'en vois vraiment aucun ;)
BeOS le faisait il y a 20 ans !
[^] # Re: incomprehensible
Posté par Victor . Évalué à 3.
il fallait bien sur secu :>
[^] # Re: incomprehensible
Posté par Dr BG (site web personnel) . Évalué à 10.
[^] # Re: incomprehensible
Posté par FReEDoM (site web personnel) . Évalué à 3.
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 :) )
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tempérer les effets d'annonce
Posté par Ph Husson (site web personnel) . Évalué à 4.
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 Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Tempérer les effets d'annonce
Posté par Anonyme . Évalué à 1.
[^] # Re: Tempérer les effets d'annonce
Posté par Eric Lacombe . Évalué à 2.
[^] # Re: Tempérer les effets d'annonce
Posté par super_mario . Évalué à 7.
Toutefois, au delà du proof-of-concept Blue Pill :
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.
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 moramarth . Évalué à 2.
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 Grumbl . Évalué à 4.
[^] # Re: relations entre TCPA et logiciels indésirables ?
Posté par moramarth . Évalué à 4.
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 Grumbl . Évalué à 1.
[^] # Re: Hein ? Quel vélo
Posté par moramarth . Évalué à 3.
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 _alex . Évalué à 3.
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 _alex . Évalué à 3.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.