Sono state rivelate informazioni su due vulnerabilità nel bootloader GRUB2, che possono portare all'esecuzione di codice utilizzando caratteri formattati in modo specifico e durante l'elaborazione di determinate sequenze Unicode. Le vulnerabilità possono essere sfruttate per eludere il meccanismo di avvio verificato UEFI Secure Boot.
Vulnerabilità identificate:
- CVE-2022-2601 — overflow del buffer nella funzione grub_font_construct_glyph() durante l'elaborazione di caratteri formattati in pf2, causato da un calcolo errato del parametro max_glyph_size e dall'allocazione di una zona di memoria notevolmente inferiore a quella necessaria per contenere i glifi.
- CVE-2022-3775 — scrittura oltre l'area di memoria allocata durante il rendering di alcune sequenze Unicode con un carattere formattato in modo specifico. Il problema è presente nel codice di elaborazione dei caratteri ed è causato dalla mancanza di adeguati controlli di corrispondenza della larghezza e dell'altezza del glifo con le dimensioni della mappa di bit disponibile. L'attaccante può scegliere un input in modo da provocare la scrittura dei dati oltre i limiti del buffer allocato. Va notato che, nonostante la complessità di sfruttare la vulnerabilità, non si esclude la possibilità di eseguire codice.
La correzione è stata pubblicata sotto forma di patch. Lo stato di risoluzione delle vulnerabilità nelle distribuzioni può essere valutato su queste pagine: Ubuntu, SUSE, RHEL, Fedora, Debian. Per risolvere i problemi in GRUB2 non è sufficiente aggiornare il pacchetto, ma è necessario anche generare nuove firme digitali interne e aggiornare gli installer, i bootloader, i pacchetti del kernel, i firmware fwupd e il layer shim.
Nella maggior parte delle distribuzioni Linux, per l'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, consentendo agli sviluppatori delle distribuzioni di non dover firmare ogni aggiornamento del kernel e di GRUB in Microsoft. Le vulnerabilità in GRUB2 consentono di eseguire codice proprio dopo una verifica riuscita di shim, ma prima dell'avvio del sistema operativo, infiltrandosi nella catena di fiducia in modalità Secure Boot attiva e ottenendo il pieno controllo sul processo di avvio, inclusa l'avvio di un altro sistema operativo, la modifica dei componenti del sistema operativo e il bypass delle protezioni 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
