Des chercheurs de l'équipe Google Project Zero ont dévoilé il y a quelques jours dans un article de blog que ont identifié une vulnérabilité (CVE-2021-29657) dans l'hyperviseur KVM (un hyperviseur open source basé sur Linux qui prend en charge la virtualisation à accélération matérielle sur x86, ARM, PowerPC et S/390) qui permet d'éviter l'isolement du système invité et exécutez votre code du côté de l'environnement hôte.
Le message mentionne que le problème manifestes du noyau Linux 5.10-rc1 à v5.12-rc6, es decir, ne couvre que les noyaux 5.10 et 5.11 (La plupart des branches stables des distributions n'ont pas été affectées par le problème.) Le problème est présent dans le mécanisme nested_svm_vmrun, implémenté à l'aide de l'extension AMD SVM (Secure Virtual Machine) et permettant le lancement imbriqué de systèmes invités.
Dans cet article de blog, je décris une vulnérabilité dans le code KVM spécifique à AMD et explique comment ce bogue peut se transformer en une évasion complète de la machine virtuelle. Pour autant que je sache, il s'agit de la première rédaction publique d'une rupture client-hôte KVM qui ne repose pas sur des bogues dans les composants de l'espace utilisateur comme QEMU.
Le bogue discuté a été attribué à CVE-2021-29657, affecte les versions du noyau v5.10-rc1 à v5.12-rc6 et a été corrigé fin mars 2021. Comme le bogue n'est devenu exploitable qu'en v5.10 et a été découvert environ 5 mois plus tard, la plupart des déploiements KVM réels ne devraient pas être affectés. Je pense toujours que le problème est une étude de cas intéressante dans le travail requis pour créer une évasion stable d'invité à hôte contre KVM et j'espère que cet article pourra démontrer que les compromissions d'hyperviseur ne sont pas seulement des problèmes théoriques.
Les chercheurs mentionnent que pour la bonne mise en œuvre de cette fonctionnalité, l'hyperviseur doit intercepter toutes les instructions SVM exécuter sur des systèmes invités, émuler son comportement et synchroniser l'état avec le matériel, ce qui est une tâche assez difficile.
Après avoir analysé l'implémentation KVM proposée, les chercheurss a rencontré une erreur logique qui autorise le contenu du MSR (Enregistrement spécifique au modèle) de l'hôte être influencé par le système invité, qui peut être utilisé pour exécuter du code au niveau de l'hôte.
En particulier, l'exécution d'une opération VMRUN à partir d'un deuxième invité de niveau imbriqué (L2 lancé à partir d'un autre invité) entraîne un deuxième appel à nested_svm_vmrun et corrompt la structure svm-> nested.hsave, qui est superposée aux données de vmcb du système invité L2. .
En conséquence, une situation se présente où au niveau de l'invité L2, il est possible de libérer de la mémoire dans la structure svm-> nested.msrpm, qui stocke le bit MSR, même s'il continue d'être utilisé, et d'accéder au MSR de l'hôte environnement. .
Cela signifie, par exemple, que la mémoire d'un invité peut être inspectée en vidant la mémoire allouée de son processus d'espace utilisateur ou que les limites de ressources pour le temps CPU et la mémoire peuvent être facilement appliquées.
De plus, KVM peut décharger la plupart du travail lié à l'émulation des appareils vers le composant de l'espace utilisateur.
Le problème est présent dans le code utilisé sur les systèmes équipés de processeurs AMD (module kvm-amd.ko) et n'apparaît pas sur les processeurs Intel.
En dehors de quelques périphériques sensibles aux performances et traitant de la gestion des interruptions, tout le code complexe de bas niveau permettant de fournir un accès au disque virtuel, au réseau ou au GPU peut être déployé dans l'espace utilisateur.
Les chercheurs en plus de décrire le problème ils ont également préparé un prototype fonctionnel d'un exploit qui permet d'exécuter un shell root depuis un environnement invité dans un environnement hôte sur un système doté d'un processeur AMD Epyc 7351P et d'un noyau Linux 5.10.
On observe que c'est le premier invité à héberger la vulnérabilité dans l'hyperviseur KVM lui-même, pas lié à des bogues dans les composants de l'espace utilisateur comme QEMU. Le correctif a été accepté dans le noyau fin mars.
Enfin si vous souhaitez en savoir plus à propos de la note, vous pouvez vérifier les détails dans le lien suivant.