Virtualisation et sécurité

Timothée Ravier (@siosm) - https://tim.siosm.fr/cours

5e année cycle ingénieur, filière STI

Option Sécurité des Systèmes Ubiquitaires

2021-2022

Virtualisation avec KVM/QEMU

Principe général : KVM & VT-x (Intel)

center

Création d'une VM avec QEMU

center

Matériel émulé (QEMU) : envoi

center

Matériel émulé (QEMU) : réception

center

Matériel virtuel : VirtIO (QEMU)

center

Matériel virtuel : VirtIO (Kernel)

center

Composants émulés (QEMU)

center

Composants émulés (Kernel)

center

Scénarios d'attaque et vulnérabilités

Virtualisation == sécurité ?

La virtualisation n'est pas un composant de sécurité !

Virtualisation == sécurité ?

Plus d'isolation, mais :

  • Matériel plus compliqué
  • Plus de versions de systèmes (noyau, espace utilisateur)
  • Plus de réseaux à gérer
  • Plus d'interfaces d'administration

Virtualisation == sécurité ?

  • La virtualisation ne dispense donc pas des autres solutions pour assurer la sécurité
  • Au contraire, elle en ajoute à appliquer

Virtualisation == sécurité ?

Pour s'en convaincre, il faut comparer :

  • Services sur des machines physiquement distinctes vs machines virtuelles

center

Virtualisation == sécurité?

Pour s'en convaincre, il faut comparer :

  • Services sur une même machine vs services dans une ou plusieurs machines virtuelles

center

Scénario d'attaque

Scénario d'attaque : Machine virtuelle

  • La machine virtuelle (le système, les services ou les données) sont visés
  • Principalement des attaques à distance similaires aux attaques classiques pour les machines physiques
  • Les machines virtuelles ne sont pas exemptées des contraintes de sécurité appliquées aux machines physique

Scénario d'attaque : Autres VMs

  • Corrompre ou espionner les autres machines virtuelles sur le même hyperviseur

Scénario d'attaque : Système hôte

  • Sortir de la machine virtuelle pour attaquer le système hôte et les autres machines virtuelles
  • Attaquer ou corrompre l'hyperviseur :
    • faille dans l'hyperviseur ou les drivers virtuels
    • faille dans le système hôte

Scénario d'attaque : Virtualisation à la volée

  • Virtualiser à la volée un système non-virtualisé sans visibilité pour l'utilisateur
  • Théoriquement possible (Blue Pill)
  • Invisibilité contestée en pratique: il est très difficile de masquer à un système qu'il est virtualisé

Historique des vunérabilités

Xen

QEMU (1)

QEMU (2)

  • VENOM, don’t get bitten (CVE-2015-3456) :
    • Bug dans le pilote du contrôler de disquettes émulé par QEMU
    • Impacte tous les hyperviseurs
    • Activé par défaut dans toutes les machines virtuelles sans possibilité de le désactiver à l'exécution
    • Nécessite d'être root la machine virtuelle
    • Prise de contrôle de QEMU en Ring 3 mode VMX Root (« sortir » de la machine virtuelle)

KVM

Hôte : VirtIO

  • Faille driver VirtIO :
    • CVE-2011-4127: privilege escalation from qemu / KVM guests
    • Nécessite d'être root la machine virtuelle
    • Donne l'accès total à un disque physique SCSI de l'hôte car le noyau ne vérifiait pas que les commandes SCSI correspondaient uniquement à des parties accessibles à la VM
    • Faille dans le noyau hôte

Hôte : système de fichier

  • Il est très fortement déconseillé de monter directement le système de fichiers d'une machine virtuelle sur la machine hôte :
  • Il faut donc utiliser d'autres outils qui le font indirectement avec FUSE : libguestfs

Virtualisation et sécurité

Eléments à durcir

  • Sécurité de l'hyperviseur :
    • Matériel / Noyau / OS
    • Gestionnaire de machines virtuelles (VMM)
    • Emulateur / virtualiseur
    • Isolation entre les machines virtuelles
  • Sécurité des machines virtuelles :
    • Noyau / OS
    • Applications
    • Mise à jour
  • Sécurité des images de machines virtuelles :
    • Distribution et intégrité
    • Distribution des secrets

Matériel

  • Matériel sécurisé ?
  • Canaux cachés
  • Matériel de confiance
  • Cf. chapitre sur la sécurité des conteneurs.

Matériel : support de la virtualisation

Surface d'attaque supplémentaire :

IOMMU & PCI passthrouh

  • IOMMU intéressante dans tous les cas : contrôle d'accès entre prériphériques PCI-Express
  • PCI passthrough et SR-IOV à éviter :
    • firmware du matériel accessible ?
    • interfaces cachées ?
    • quelle isolation entre les différents contextes par le matériel ?
    • exemple: cartes graphiques : XDC2012: Graphics stack security
  • Utiliser VFIO

Network Function Virtualization, Packet Processing Performance of Virtualized Platforms with Linux and Intel Architecture

Noyau Linux

  • Point commun entre toutes les machines virtuelles
  • Hyperviseur: module KVM : (~30k SLOC)
    • /dev/kvm: interface iotcl
    • 2 hypercalls: KVM_HC_VAPIC_POLL_IRQ (\Leftrightarrow VM_EXIT) et KVM_HC_KICK_CPU
  • Drivers spécifiques :
    • vhost-net
    • vhost-scsi

Durcissement KVM

Eviter :

Eviter Xen

  • De très nombreuses vulnérabilités: https://xenbits.xen.org/xsa/
  • Dernier Cloud provider majeur: Amazon AWS
  • Migration en cours vers KVM (Nitro)

Ducissement du noyau Linux

  • Cf. chapitre sur la sécurité des conteneurs

Système d'exploitation

  • Le système d'exploitation hôte de l'hyperviseur est un système classique
  • Cf. chapitre sur la sécurité des conteneurs

Gestionnaire de machines virtuelles (VMM)

  • VMM généralement très privilégié :
    • Gestion du réseaux, des images disques, des secrets, etc.
  • Contrôle des accès au VMM :
    • Accès au VMM \Leftrightarrow root
    • Situation similaire à Docker
  • Exemple pour libvirt :
    • Accès à la socket libvirt en local
    • Accès à distance en TCP

Durcissement de l'émulateur / virtualiseur

  • Emulateur : QEMU (~500k SLOC)
  • Processus en espace utilisateur :
  • Durcissement : Réduction de la surface d'attaque :
    • Utiliser le moins possible d'émulateurs de matériel
    • Options de compilation et durcissement

Alternatives à QEMU ?

Cloud providers ?

Isolation entre les machines virtuelles

  • Confinement des machines virtuelles \Rightarrow confinement de l'émulateur / virtualiseur
  • Réduction de la surface d'attaque du noyau : seccomp-bpf
  • Isolation avec SELinux :
    • Confinement des instances de QEMU à l'aide des catégories (sVirt)
    • Ensembles de catégories associées aux images disques des machines virtuelles
  • Voir chapitre sur la sécurité des conteneurs

Sécurité des machines virtuelles

  • Système d'exploitation complet
  • Contraintes similaires : mise à jour, durcissement, etc.
  • Voir chapitre sur la sécurité des conteneurs

Sécurité des machines virtuelles : root

  • Protection du compte root et du noyau impérative
  • La quasi totalité des vulnérabilités dans les hyperviseurs nécessitent d'être root (Ring 0) dans la machine virtuelle
  • Séparation de privilèges et défense en profondeur nécessaire

Entropie dans une machine virtuelle

  • Beaucoup de composants matériels émulés dans une VM
  • Comportement très peu aléatoire
  • Entropie de mauvaise qualité
  • Une seule solution : VirtIO-RNG
  • Attention aux « fausses bonnes idées » (haveged, pollinate, etc.)

Images de machines virtuelles

  • Vérifier l'origine et l'intégrité des images de machines virtuelles
  • Considérer les images de machines virtuelles comme publiques
  • Utiliser d'autres mécanismes pour provisionner des secrets :
    • cloud-init, Ignition, user-data, etc.

Surtout ne pas oublier l'analyse des risques !

center

http://xkcd.com/538/

Suite

Sécurité des infrastructures

# Alternatives à QEMU ? (Prototypes et expériences) - lkvm / Native KVM tool ([Stand-alone KVM tool](https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git)) : virtualisateur, périphériques virtio et guests Linux uniquement - [novm](https://github.com/google/novm) (Google) : Go, périphériques virtio, expérimental - [NEMU](https://github.com/intel/nemu) (Intel) : version « nettoyée » de QEMU ---