Nel framework InsydeH2O, utilizzato da molti produttori per creare firmware UEFI per le proprie apparecchiature (l'implementazione più comune di UEFI BIOS), sono state identificate 23 vulnerabilità che consentono l'esecuzione del codice a livello SMM (System Management Mode), che ha un priorità più alta (Ring -2) rispetto alla modalità hypervisor e un anello di protezione pari a zero e accesso illimitato a tutta la memoria. Il problema riguarda il firmware UEFI utilizzato da produttori come Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel e Bull Atos.
Lo sfruttamento delle vulnerabilità richiede l'accesso locale con diritti di amministratore, il che rende i problemi popolari come vulnerabilità di secondo livello, utilizzate dopo lo sfruttamento di altre vulnerabilità nel sistema o l'uso di metodi di ingegneria sociale. L'accesso a livello SMM consente di eseguire codice a un livello non controllato dal sistema operativo, che può essere utilizzato per modificare il firmware e lasciare codice dannoso o rootkit nascosti nella SPI Flash che non vengono rilevati dal sistema operativo, nonché per disabilitare la verifica in fase di avvio (UEFI Secure Boot, Intel BootGuard) e attacchi agli hypervisor per aggirare i meccanismi di controllo dell'integrità degli ambienti virtuali.
Lo sfruttamento delle vulnerabilità può essere effettuato dal sistema operativo utilizzando gestori SMI (System Management Interrupt) non verificati, nonché nella fase di pre-esecuzione del sistema operativo durante le fasi iniziali dell'avvio o del ritorno dalla modalità di sospensione. Tutte le vulnerabilità sono causate da problemi di memoria e sono divise in tre categorie:
- Callout SMM: esecuzione del codice con diritti SMM reindirizzando l'esecuzione dei gestori di interrupt SWSMI al codice esterno alla SMRAM;
- Corruzione della memoria che consente a un utente malintenzionato di scrivere i propri dati nella SMRAM, una speciale area di memoria isolata in cui il codice viene eseguito con diritti SMM.
- Danneggiamento della memoria nel codice in esecuzione a livello DXE (Driver eXecution Environment).
Per dimostrare i principi di organizzazione di un attacco, è stato pubblicato un esempio di exploit che consente, attraverso un attacco dal terzo o zero anello di protezione, di accedere al DXE Runtime UEFI ed eseguire il proprio codice. L'exploit manipola uno stack overflow (CVE-2021-42059) nel driver UEFI DXE. Durante l'attacco l'aggressore può inserire il proprio codice nel driver DXE, che rimane attivo anche dopo il riavvio del sistema operativo, oppure apportare modifiche all'area NVRAM della SPI Flash. Durante l'esecuzione, il codice dell'utente malintenzionato può apportare modifiche alle aree di memoria privilegiate, modificare i servizi EFI Runtime e influenzare il processo di avvio.
Fonte: opennet.ru