Nel driver che gestisce il file system NTFS nel bootloader GRUB2, è stata individuata una vulnerabilità (CVE-2023-4692) che consente di eseguire codice personalizzato a livello di bootloader quando si accede a un'immagine di file system appositamente formattata. La vulnerabilità può essere utilizzata per aggirare il meccanismo di avvio verificato UEFI Secure Boot.
La vulnerabilità è causata da un errore nel codice di analisi dell'attributo NTFS «$ATTRIBUTE_LIST» (grub-core/fs/ntfs.c), che può essere sfruttato per scrivere informazioni controllate dall'utente in un'area di memoria al di fuori del buffer allocato. Quando si gestisce un'immagine NTFS appositamente formattata, il buffer overflow porta a sovrascrivere parte della memoria di GRUB e, in determinate condizioni, a danneggiare l'area di memoria del firmware UEFI, il che consente potenzialmente di eseguire codice personalizzato a livello di bootloader o firmware.
Inoltre, nel driver NTFS di GRUB2 è stata individuata un'altra vulnerabilità (CVE-2023-4693) che consente di leggere il contenuto di un'area di memoria arbitraria durante l'analisi dell'attributo «$DATA» in un'immagine NTFS appositamente formattata. Tra l'altro, questa vulnerabilità consente di estrarre dati riservati memorizzati nella memoria o di determinare i valori delle variabili EFI.
Al momento, i problemi sono stati risolti solo tramite un patch. Lo stato delle vulnerabilità nelle distribuzioni può essere valutato a queste pagine: Debian, Ubuntu, SUSE, RHEL, Fedora. Per risolvere i problemi in GRUB2 non è sufficiente aggiornare il pacchetto, è necessario anche generare nuove firme digitali interne e aggiornare installer, bootloader, pacchetti del kernel, firmware fwupd e shim.
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 della lista 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 nelle distribuzioni. Prima dell'implementazione di SBAT, l'aggiornamento della lista dei certificati revocati (dbx, UEFI Revocation List) era una condizione necessaria per il blocco completo della vulnerabilità, poiché un attaccante, indipendentemente dal sistema operativo utilizzato, poteva compromettere il Secure Boot UEFI utilizzando il caricatore
Fonte: opennet.ru
