Tag: hyperviseur

Voici un projet qui me (Wenzel) tient à cœur : pyvmidbg.

Le but est assez simple: se donner la capacité de déboguer l’état complet d’un système d’exploitation, tournant dans une machine virtuelle, en utilisant uniquement l’hyperviseur et l’accès au matériel de la VM.

L’idée en elle-même a commencé à germer lorsque je travaillais sur des outils d’analyse de malware basés sur l’hyperviseur, et, voyant leur efficacité pour l’analyse automatisée, j’ai petit à petit creusé pour transposer ces concepts afin d’aboutir à de puissants débogueurs interactifs.

Intérêt

Problématiques

L’intérêt d’un tel outil ?
Au-delà du besoin évident pour des analystes en sécurité d’analyser furtivement des malwares avancés, on peut trouver d’autres problèmes plus généraux liés aux API de débogage des OS :

  1. La visibilité (l’effet d’observateur), qui va potentiellement changer l’environnement du programme. Par exemple certains appels systèmes auront un comportement différent ;
  2. cet effet d’observateur peut parfois être volontaire, dans une tentative de protection de la propriété intellectuelle de certains OS ;
  3. les nouvelles fonctionnalités de sécurité des OS modernes posent des soucis de compatibilité avec la visibilité et le contrôle total que demandent les débogueurs.

Avantages

Déboguer depuis l’hyperviseur apporte aussi des bénéfices non négligeables:

  1. en virtualisant le démarrage depuis un hyperviseur chargé sur une clé USB, il est possible d’analyser dans une machine virtuelle l’ensemble de la séquence de démarrage d’un OS, et ce depuis le BIOS/UEFI ;
  2. les unikernels, images noyau embarquant une seule application, sont dépouillés d’un maximum de fonctionnalités pour être minimaux et rapides. Le stub de débogage est également supprimé, laissant à l’API de l’hyperviseur les seuls moyens d’accès pour un unikernel en production ;
  3. l’unification des outils de débogage : en rebasant nos débogueurs sur l’hyperviseur, il nous sera possible d’utiliser le même outil pour déboguer et suivre des processus, de l’espace utilisateur au noyau, et ce sur tous les OS !

Full-system debugging

Afin de résoudre ces problématiques et implémenter une solution pérenne, j’aimerais vous présenter la vision que j’ai de nos futurs outils de déboguage, travaillant en mode full-system:

pyvmidbg

  • les multiples stubs de débogage implémentent les protocoles standard pour supporter tous les frontaux ;
  • les stubs possèdent une connaissance du système invité, c’est-à-dire qu’ils sont capables de suivre et d’intercepter l’exécution d’un processus cible dans la machine virtuelle ;
  • la LibVMI permet de faire le lien avec les différentes APIs de VMI (Virtual Machine Introspection) des hyperviseurs cibles.

Démo

Comme une démo vaudra mieux que mille mots, je vous propose cette petite vidéo que j’ai enregistrée pour la conférence Insomni’Hack qui se tenait la semaine dernière à Genève.

Dans celle-ci, avec une VM Windows XP en nested, je montre comment :

  1. intercepter l’exécution de cmd.exe ;
  2. se connecter au stub en utilisant radare2 ;
  3. mettre en place deux points d’arrêt, en espace utilisateur sur ntdll!NtOpenFile, puis en espace noyau sur nt!NtOpenFile ;
  4. suivre des événements liés à ces points d’arrêt dans le stub, en ignorant les autres processus pour ne renvoyer de résultat que pour cmd.exe.

Pour aller plus loin, je vous ai également mis le lien vers la présentation.

  • Quel est votre avis concernant nos outils de débogages actuels ? J’aimerais avoir vos retours !
  • Je cherche à présent à implémenter le support pour Linux, et à comprendre comment l’état des threads est sauvé/restauré, et comment l’ordonnanceur passe de l’un à l’autre.
  • Vous êtes curieux ou souhaitez participer ? nous avons un Slack !

Dans l’espoir de vous présenter une meilleure version au FOSDEM 2020 🙂

Merci à vous !

Commentaires :
voir le flux atom
ouvrir dans le navigateur

Read more