Sono state divulgate informazioni su 8 vulnerabilità nel bootloader GRUB2, che consentono di eludere il meccanismo UEFI Secure Boot e avviare codice non verificato, ad esempio per inserire malware che opera a livello di bootloader o kernel.
Ricordiamo che nella maggior parte delle distribuzioni Linux, per l'avvio verificato in modalità UEFI Secure Boot viene utilizzato un piccolo strato shim, certificato con una firma digitale di Microsoft. Questo strato verifica GRUB2 con un proprio certificato, il che consente agli sviluppatori delle distribuzioni di non certificare ogni aggiornamento del kernel e di GRUB presso Microsoft. Le vulnerabilità in GRUB2 consentono di eseguire il proprio codice in una fase dopo la verifica riuscita di shim, ma prima del caricamento del sistema operativo, interrompendo la catena di fiducia in modalità Secure Boot attiva e ottenendo il pieno controllo del processo di avvio successivo, inclusa l'avviabilità di un altro sistema operativo, la modifica dei componenti del sistema operativo e l'elusione della protezione Lockdown.
Come nel caso della vulnerabilità BootHole dello scorso anno, per bloccare questo problema non è sufficiente aggiornare il bootloader, poiché l'attaccante, indipendentemente dal sistema operativo utilizzato, può compromettere UEFI Secure Boot utilizzando un supporto di avvio con una vecchia versione vulnerabile di GRUB2, certificata con una firma digitale. Il problema viene risolto solo aggiornando l'elenco dei certificati revocati (dbx, UEFI Revocation List), ma in questo caso si perderà la possibilità di utilizzare vecchi supporti di installazione con Linux.
Su sistemi con firmware in cui è stato aggiornato l'elenco dei certificati revocati, in modalità UEFI Secure Boot sarà possibile avviare solo versioni aggiornate delle distribuzioni Linux. Le distribuzioni dovranno aggiornare gli installer, i bootloader, i pacchetti del kernel, le firmware fwupd e lo strato shim, generando nuove firme digitali per essi. Gli utenti dovranno aggiornare le immagini di installazione e altri supporti di avvio, oltre a caricare l'elenco dei certificati revocati (dbx) nel firmware UEFI. Fino all'aggiornamento di dbx in UEFI, il sistema rimane vulnerabile indipendentemente dagli aggiornamenti installati nel sistema operativo. Lo stato della risoluzione delle vulnerabilità può essere valutato su queste pagine: Ubuntu, SUSE, RHEL, Debian.
Per risolvere i problemi che sorgono con la distribuzione dei certificati revocati, in futuro si prevede di utilizzare il meccanismo SBAT (UEFI Secure Boot Advanced Targeting), il cui supporto è implementato per GRUB2, shim e fwupd, e a partire dai prossimi aggiornamenti verrà utilizzato al posto della funzionalità fornita dal pacchetto dbxtool. SBAT è stato sviluppato in collaborazione con Microsoft e prevede l'aggiunta di nuovi metadati nei file eseguibili dei componenti UEFI, che includono informazioni sul produttore, sul prodotto, sul componente e sulla versione. I metadati indicati vengono firmati digitalmente e possono essere inclusi anche nelle liste di componenti autorizzati o vietati per UEFI Secure Boot. Pertanto, SBAT consentirà di manipolare i numeri di versione dei componenti in caso di revoca, senza la necessità di rigenerare le chiavi per Secure Boot e senza creare nuove firme per il kernel, shim, grub2 e fwupd.
Vulnerabilità identificate:
- CVE-2020-14372 — tramite il comando acpi in GRUB2, un utente privilegiato del sistema locale può caricare tabelle ACPI modificate, posizionando SSDT (Secondary System Description Table) nella directory /boot/efi e modificando le impostazioni in grub.cfg. Nonostante l'attivazione della modalità Secure Boot, l'SSDT proposto verrà eseguito dal kernel e può essere utilizzato per disabilitare la protezione LockDown, che blocca i percorsi di bypass di UEFI Secure Boot. Di conseguenza, l'attaccante può riuscire a caricare il proprio modulo kernel o eseguire codice tramite il meccanismo kexec, senza alcun controllo della firma digitale.
- CVE-2020-25632 — accesso a un'area di memoria già liberata (use-after-free) nell'implementazione del comando rmmod, che si manifesta quando si tenta di scaricare un qualsiasi modulo senza considerare le dipendenze associate. La vulnerabilità non esclude la creazione di un exploit, che potrebbe portare all'esecuzione di codice bypassando la verifica di Secure Boot.
- CVE-2020-25647 — scrittura oltre il limite del buffer nella funzione grub_usb_device_initialize(), chiamata durante l'inizializzazione dei dispositivi USB. Il problema può essere sfruttato collegando un dispositivo USB appositamente preparato, che fornisce parametri le cui dimensioni non corrispondono a quelle del buffer allocato per le strutture USB. L'attaccante può quindi eseguire codice non verificato in Secure Boot tramite manipolazioni con i dispositivi USB.
- CVE-2020-27749 — overflow di buffer nella funzione grub_parser_split_cmdline(), che può essere provocato specificando nella linea di comando di GRUB2 variabili di dimensione superiore a 1 KB. La vulnerabilità consente di eseguire codice bypassando il Secure Boot.
- CVE-2020-27779 — il comando cutmem consente a un attaccante di rimuovere un intervallo di indirizzi dalla memoria per bypassare il Secure Boot.
- CVE-2021-3418 — le modifiche in shim_lock hanno creato un ulteriore vettore per sfruttare la vulnerabilità dell’anno scorso CVE-2020-15705. Durante l'installazione in dbx di un certificato utilizzato per firmare GRUB2, GRUB2 consentiva di caricare direttamente qualsiasi kernel senza controllare la firma.
- CVE-2021-20225 — possibilità di scrivere dati oltre il buffer durante l'esecuzione di comandi con un numero molto elevato di opzioni.
- CVE-2021-20233 — possibilità di scrivere dati al di fuori del buffer a causa di un calcolo errato della dimensione del buffer quando si utilizzano le virgolette. Nel calcolo della dimensione si presumeva che per eseguire l’escape di un apostrofo fossero necessari tre simboli, mentre in realtà ne servono quattro.
Fonte: opennet.ru
