Sono state divulgate informazioni su 8 vulnerabilità nel bootloader GRUB2, che consentono di aggirare il meccanismo UEFI Secure Boot ed eseguire codice non verificato, ad esempio, implementare malware in esecuzione 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 livello shim, firmato digitalmente da Microsoft. Questo livello verifica GRUB2 con il proprio certificato, che consente agli sviluppatori di distribuzioni di non far certificati da Microsoft tutti i kernel e gli aggiornamenti di GRUB. Le vulnerabilità in GRUB2 consentono di eseguire il codice nella fase successiva alla verifica shim riuscita, ma prima di caricare il sistema operativo, incuneandosi nella catena di fiducia quando la modalità Secure Boot è attiva e ottenendo il pieno controllo sull'ulteriore processo di avvio, incluso caricamento di un altro sistema operativo, modifica dei componenti del sistema operativo e esclusione della protezione di blocco.
Come nel caso della vulnerabilità BootHole dell'anno scorso, l'aggiornamento del bootloader non è sufficiente per bloccare il problema, poiché un utente malintenzionato, indipendentemente dal sistema operativo utilizzato, può utilizzare un supporto di avvio con una vecchia versione vulnerabile di GRUB2, firmata digitalmente, per compromettere UEFI Secure Boot. Il problema può essere risolto solo aggiornando l'elenco di revoche dei certificati (dbx, UEFI Revocation List), ma in questo caso si perderà la possibilità di utilizzare i vecchi supporti di installazione con Linux.
Sui sistemi con firmware dotato di un elenco di revoche di certificati aggiornato, solo le build aggiornate delle distribuzioni Linux possono essere caricate in modalità UEFI Secure Boot. Le distribuzioni dovranno aggiornare programmi di installazione, bootloader, pacchetti kernel, firmware fwupd e livello shim, generando per loro nuove firme digitali. Agli utenti verrà richiesto di aggiornare le immagini di installazione e altri supporti di avvio, nonché di caricare un elenco di revoche di certificati (dbx) nel firmware UEFI. Prima di aggiornare dbx a UEFI, il sistema rimane vulnerabile indipendentemente dall'installazione degli aggiornamenti nel sistema operativo. Lo stato delle vulnerabilità può essere valutato su queste pagine: Ubuntu, SUSE, RHEL, Debian.
Per risolvere i problemi che si presentano nella distribuzione dei certificati revocati, è previsto in futuro l'utilizzo del meccanismo SBAT (UEFI Secure Boot Advanced Targeting), il cui supporto è stato implementato per GRUB2, shim e fwupd, e a partire dai prossimi aggiornamenti sarà utilizzato al posto della funzionalità fornita dal pacchetto dbxtool. SBAT è stato sviluppato in collaborazione con Microsoft e prevede l'aggiunta di nuovi metadati agli eseguibili dei componenti UEFI, che includono informazioni su produttore, prodotto, componente e versione. I metadati specificati sono certificati con una firma digitale e possono inoltre essere inclusi negli elenchi dei componenti consentiti o vietati per UEFI Secure Boot. Pertanto, SBAT consentirà alla revoca di manipolare i numeri di versione dei componenti senza la necessità di rigenerare le chiavi per Secure Boot e senza generare nuove firme per kernel, shim, grub2 e fwupd.
Vulnerabilità identificate:
- CVE-2020-14372 – Utilizzando il comando acpi in GRUB2, un utente privilegiato sul sistema locale può caricare tabelle ACPI modificate inserendo una SSDT (Secondary System Description Table) nella directory /boot/efi e modificando le impostazioni in grub.cfg. Sebbene la modalità Secure Boot sia attiva, l'SSDT proposto verrà eseguito dal kernel e potrà essere utilizzato per disabilitare la protezione LockDown che blocca i percorsi di bypass UEFI Secure Boot. Di conseguenza, un utente malintenzionato può caricare il suo modulo del kernel o eseguire codice tramite il meccanismo kexec, senza verificare la firma digitale.
- CVE-2020-25632 è un accesso alla memoria use-after-free nell'implementazione del comando rmmod, che si verifica quando si tenta di scaricare qualsiasi modulo senza tenere conto delle dipendenze ad esso associate. La vulnerabilità non esclude la creazione di un exploit che potrebbe portare all'esecuzione di codice aggirando la verifica Secure Boot.
- CVE-2020-25647 Una scrittura fuori dai limiti nella funzione grub_usb_device_initialize() chiamata durante l'inizializzazione dei dispositivi USB. Il problema può essere sfruttato collegando un dispositivo USB appositamente predisposto che produce parametri la cui dimensione non corrisponde alla dimensione del buffer allocato per le strutture USB. Un utente malintenzionato può ottenere l'esecuzione di codice non verificato in Secure Boot manipolando i dispositivi USB.
- CVE-2020-27749 è un overflow del buffer nella funzione grub_parser_split_cmdline(), che può essere causato specificando variabili più grandi di 2 KB sulla riga di comando di GRUB1. La vulnerabilità consente all'esecuzione del codice di ignorare Secure Boot.
- CVE-2020-27779 – Il comando cutmem consente a un utente malintenzionato di rimuovere un intervallo di indirizzi dalla memoria per bypassare Secure Boot.
- CVE-2021-3418 - Le modifiche a shim_lock hanno creato un vettore aggiuntivo per sfruttare la vulnerabilità CVE-2020-15705 dello scorso anno. Installando il certificato utilizzato per firmare GRUB2 in dbx, GRUB2 ha consentito il caricamento diretto di qualsiasi kernel senza verificare la firma.
- CVE-2021-20225 - Possibilità di scrivere dati fuori limite durante l'esecuzione di comandi con un numero molto elevato di opzioni.
- CVE-2021-20233 - Possibilità di scrivere dati fuori limite a causa del calcolo errato della dimensione del buffer quando si utilizzano le virgolette. Nel calcolare la dimensione, si è ipotizzato che fossero necessari tre caratteri per sfuggire a una singola virgoletta, quando in realtà ne erano necessari quattro.
Fonte: opennet.ru