Les évasions guest-to-host d'ESXi publiées se regroupent étroitement autour des mêmes modèles de périphériques, car c'est là que les données contrôlées par l'invité sont analysées dans le processus vmx. Connaître le motif permet à un attaquant de faire correspondre un build ESXi cible au composant le plus susceptible de porter un bug utilisable. Les grappes récurrentes :
- Contrôleurs USB : les modèles UHCI puis XHCI ont produit à plusieurs reprises des bugs de hors-limites et de use-after-free dans la gestion des descripteurs et des anneaux ; l'USB a été un vecteur d'évasion fréquent à Pwn2Own.
- Graphismes SVGA 3D : la gestion des surfaces, des shaders et du flux de commandes dans le chemin 3D a produit des écritures hors limites et des type-confusions, un incontournable de la recherche d'évasion VMware.
- NIC vmxnet3 et e1000 : la gestion des anneaux et des descripteurs, et l'interface de configuration vmxnet3, ont porté des bugs d'accès hors limites.
- GuestRPC et VMCI : les gestionnaires RPC de dossiers partagés (HGFS) et de glisser-déposer/copier-coller, et le traitement des datagrammes VMCI, ont produit des évasions par corruption mémoire partagées avec les produits de bureau.
Exploiter le motif#
# fingerprint the exact ESXi build to match against advisories
vmware -v 2>/dev/null; esxcli system version get 2>/dev/null
# from a guest, confirm which vulnerable device models are present/enabled
lspci -nn; lsusb # XHCI present? vmxnet3 vs e1000?
# 3D acceleration enabled (SVGA 3D surface reachable)?
grep -i mks /vmfs/volumes/*/*/*.vmx 2>/dev/null # mks.enable3d = TRUE
Une approche pratique consiste à énumérer lesquels de ces modèles la VM cible expose et lesquels sont activés (accélération 3D, version spécifique du contrôleur USB, type de NIC), puis à faire correspondre le build ESXi à l'avis pour ce composant. Les évasions sont spécifiques au build et nécessitent généralement une fuite défaisant l'ASLR associée à la primitive de corruption mémoire.
Notes d'exploitation#
- La configuration du périphérique compte : l'accélération 3D et la version du contrôleur USB sont définies par VM, de sorte que la surface accessible dépend des paramètres
.vmx, pas seulement de la version d'ESXi. - Les produits de bureau (Workstation, Fusion) partagent le code SVGA, USB et GuestRPC, donc une évasion dans l'un indique souvent la même classe de bug dans les autres ; voir Exploits d'évasion connus là-bas.
- Traitez ceci comme une aide à la correspondance, pas comme une source d'exploit prête à copier-coller ; les mécanismes sont sur les pages par périphérique sous Évasion guest-to-host.