Dans le framework InsydeH2O, utilisé par de nombreux fabricants pour créer des firmware UEFI pour leur matériel (l'implémentation UEFI BIOS la plus courante), 23 vulnérabilités ont été identifiées, permettant l'exécution de code au niveau SMM (System Management Mode), qui est de priorité supérieure (Ring -2) au mode hyperviseur et au ring zéro de protection, et qui a un accès illimité à toute la mémoire. Le problème concerne les firmware UEFI utilisés par des fabricants tels que Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel et Bull Atos.
L'exploitation des vulnérabilités nécessite un accès local avec des droits d'administrateur, ce qui rend ces problèmes prisés comme vulnérabilités de second niveau, utilisées après l'exploitation d'autres vulnérabilités dans le système ou par des méthodes d'ingénierie sociale. L'accès au niveau SMM permet d'exécuter du code à un niveau qui échappe au contrôle du système d'exploitation, ce qui peut être utilisé pour modifier des firmwares et laisser dans la mémoire SPI Flash un code malveillant ou des rootkits non détectables par le système d'exploitation, ainsi que pour désactiver la vérification au démarrage (UEFI Secure Boot, Intel BootGuard) et attaquer des hyperviseurs pour contourner les mécanismes de vérification de l'intégrité des environnements virtuels.
L'exploitation des vulnérabilités peut être réalisée depuis le système d'exploitation à l'aide de gestionnaires SMI (System Management Interrupt) non vérifiés, ainsi qu'à un stade antérieur à l'exécution du système d'exploitation pendant les premières étapes du démarrage ou lors d'un retour de mode veille. Toutes les vulnérabilités sont causées par des problèmes de gestion de la mémoire et peuvent être classées en trois catégories :
- SMM Callout — exécution de son propre code avec des droits SMM en redirigeant l'exécution des gestionnaires d'interruptions SWSMI vers du code en dehors de la SMRAM ;
- Corruptions de mémoire permettant à un attaquant d'écrire ses données dans la SMRAM, une zone de mémoire isolée où le code s'exécute avec des droits SMM.
- Corruption de mémoire dans le code exécuté au niveau DXE (Driver eXecution Environment).
Pour illustrer les principes d'organisation d'une attaque, un exemple d'exploit a été publié, permettant, par une attaque depuis la troisième ou la première couche de protection, d'accéder à DXE Runtime UEFI et d'exécuter son propre code. L'exploit manipule un débordement de pile (CVE-2021-42059) dans le pilote UEFI DXE. Au cours de l'attaque, l'agresseur peut placer son code dans un pilote DXE, qui reste actif après le redémarrage du système d'exploitation, ou apporter des modifications à la zone NVRAM dans la mémoire flash SPI. Pendant l'exécution, le code de l'agresseur peut apporter des modifications dans des zones de mémoire privilégiées, modifier les services EFI Runtime et influencer le processus de démarrage.
Source : opennet.ru
