È stato pubblicato un insieme di patch che risolvono 6 vulnerabilità nel bootloader GRUB2, la maggior parte delle quali porta a accesso alla memoria dopo il suo rilascio (use-after-free). I problemi potenzialmente identificati possono essere utilizzati per bypassare il meccanismo di avvio verificato UEFI Secure Boot. Lo stato della risoluzione delle vulnerabilità nelle distribuzioni può essere valutato sulle seguenti pagine: Debian, Ubuntu, SUSE, RHEL, Arch e Fedora. Per risolvere i problemi in GRUB2, non è sufficiente aggiornare il pacchetto, è necessario anche generare nuove firme digitali interne e aggiornare gli installer, i bootloader, i pacchetti del kernel, i firmware fwupd e il layer shim.
Vulnerabilità identificate:
- CVE-2025-61661 — scrittura oltre il buffer allocato nella funzione grub_usb_get_string(), che può essere sfruttata durante l'elaborazione delle stringhe in codifica UTF-8 e UTF-16, trasmesse al momento del collegamento di dispositivi USB. Il problema è causato dal fatto che il buffer era allocato in base alla dimensione della stringa indicata nel primo messaggio dal dispositivo USB, mentre la dimensione durante l'esecuzione della conversione della codifica veniva calcolata sulla base delle operazioni di lettura successive dal dispositivo USB. Di conseguenza, per l'attacco si può utilizzare un dispositivo USB modificato, che inizialmente restituisce un valore di dimensione ridotto.
- CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 — mancanza di pulizia degli handler dei comandi "normal", "normal_exit", "net_set_vlan" e "gettext" durante lo scarico dei moduli "normal", "net" e "gettext", che crea condizioni per l'accesso alla memoria dopo il suo rilascio (use-after-free) nel caso in cui vengano eseguiti i comandi segnati dopo lo scarico dei rispettivi moduli. Vulnerabilità simili sono state trovate anche per i comandi "functional_test" e "all_functional_test", ma non sono stati assegnati identificatori CVE, poiché questi comandi fanno parte della libreria di test e non dovrebbero essere inclusi nelle build di produzione.
- CVE-2025-54771 — errore nel conteggio dei riferimenti alle strutture "fs" nella funzione grub_file_close(), che porta a accesso alla memoria dopo il suo rilascio (use-after-free).
In gran parte delle distribuzioni Linux, per il processo di avvio verificato in modalità UEFI Secure Boot viene utilizzato un piccolo layer shim, firmato digitalmente da Microsoft. Questo layer verifica GRUB2 con il proprio certificato, permettendo agli sviluppatori delle distribuzioni di non dover firmare ogni aggiornamento del kernel e di GRUB con Microsoft. Le vulnerabilità in GRUB2 consentono di eseguire codice personalizzato dopo una verifica riuscita del shim, ma prima del caricamento del sistema operativo, infiltrandosi nella catena di fiducia durante il funzionamento del Secure Boot e ottenendo il controllo completo sul successivo processo di avvio, ad esempio, per caricare un altro sistema operativo, modificare componenti del sistema operativo e bypassare la protezione Lockdown.
Per bloccare la vulnerabilità senza revocare la firma digitale, i distributori possono utilizzare il meccanismo SBAT (UEFI Secure Boot Advanced Targeting), il cui supporto è stato implementato per GRUB2, shim e fwupd nella maggior parte dei distribuiti Linux. SBAT è stato sviluppato congiuntamente a Microsoft e implica l'aggiunta di metadati ai file eseguibili dei componenti UEFI, che includono informazioni sul produttore, prodotto, componente e versione. I metadati indicati sono firmati digitalmente e possono essere inclusi separatamente nelle liste di componenti consentiti o vietati per UEFI Secure Boot.
SBAT consente di bloccare l'uso della firma digitale per singoli numeri di versione dei componenti senza dover revocare le chiavi per il Secure Boot. Il blocco delle vulnerabilità tramite SBAT non richiede l'uso dell'elenco dei certificati revocati UEFI (dbx), ma avviene a livello di sostituzione della chiave interna per la generazione delle firme e l'aggiornamento di GRUB2, shim e altri artefatti di avvio forniti dai pacchetti. Prima dell'implementazione di SBAT, l'aggiornamento dell'elenco dei certificati revocati (dbx, UEFI Revocation List) era una condizione necessaria per il blocco completo delle vulnerabilità, poiché un attaccante, indipendentemente dal sistema operativo utilizzato, poteva compromettere il Secure Boot UEFI utilizzando un supporto di avvio con una vecchia versione vulnerabile di GRUB2, certificata con una firma digitale.
Fonte: opennet.ru
