Nel framework InsydeH2O, utilizzato da molti produttori per creare firmware UEFI per il proprio hardware (la realizzazione di UEFI BIOS più comune), sono state identificate 23 vulnerabilità che consentono di eseguire codice a livello SMM (System Management Mode), un livello più privilegiato (Ring -2) rispetto alla modalità ipervisor e al ring zero di protezione, con accesso illimitato all'intera memoria. Il problema riguarda i firmware UEFI utilizzati da produttori come Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel e Bull Atos.
Per sfruttare le vulnerabilità è necessario un accesso locale con privilegi di amministratore, il che rende questi problemi ricercati come vulnerabilità di secondo livello, utilizzate dopo aver sfruttato altre vulnerabilità nel sistema o utilizzando tecniche di ingegneria sociale. L'accesso di livello SMM consente l'esecuzione di codice a un livello non controllato dal sistema operativo, il che può essere utilizzato per modificare firmware e lasciare codice malevolo o rootkit nascosto nel SPI Flash, non rilevabile dal sistema operativo, oltre a disabilitare la verifica nella fase di avvio (UEFI Secure Boot, Intel BootGuard) e attaccare hypervisor per bypassare i meccanismi di controllo dell'integrità degli ambienti virtuali.
Lo sfruttamento delle vulnerabilità può essere effettuato dal sistema operativo tramite handler SMI (System Management Interrupt) non verificati, così come nelle fasi iniziali di avvio o durante il ritorno dalla modalità di sospensione. Tutte le vulnerabilità sono causate da problemi di gestione della memoria e sono suddivise in tre categorie:
- SMM Callout — esecuzione del proprio codice con privilegi SMM attraverso il reindirizzamento dell'esecuzione dei gestori di interruzione SWSMI su codice esterno a SMRAM;
- Danni alla memoria che consentono a un attaccante di scrivere i propri dati in SMRAM, una zona di memoria isolata e speciale in cui viene eseguito codice con privilegi SMM.
- Corruzione di memoria nel codice eseguito nel 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 dal primo anello di protezione, di accedere al DXE Runtime UEFI e di eseguire il proprio codice. L'exploit manipola un overflow dello stack (CVE-2021-42059) nel driver UEFI DXE. Durante l'attacco, l'attaccante può posizionare il proprio codice in un driver DXE, che rimane attivo anche dopo il riavvio del sistema operativo, o apportare modifiche all'area NVRAM nella memoria SPI Flash. Durante l'esecuzione, il codice dell'attaccante può modificare aree di memoria privilegiate, modificare i servizi EFI Runtime e influenzare il processo di avvio.
Fonte: opennet.ru
