Sono state divulgate informazioni su due vulnerabilità nel bootloader GRUB2, che possono portare all'esecuzione di codice quando si utilizzano caratteri appositamente progettati e si elaborano determinate sequenze Unicode. Le vulnerabilità possono essere utilizzate per bypassare il meccanismo di avvio verificato UEFI Secure Boot.
Vulnerabilità identificate:
- CVE-2022-2601 - Un buffer overflow nella funzione grub_font_construct_glyph() durante l'elaborazione di caratteri appositamente progettati nel formato pf2, che si verifica a causa di un calcolo errato del parametro max_glyph_size e dell'allocazione di un'area di memoria ovviamente più piccola del necessario ospitare i glifi.
- CVE-2022-3775 Si verifica una scrittura fuori dai limiti durante il rendering di alcune sequenze Unicode in un carattere con uno stile speciale. Il problema risiede nel codice di elaborazione dei caratteri ed è causato dalla mancanza di controlli adeguati per garantire che la larghezza e l'altezza del glifo corrispondano alla dimensione della bitmap disponibile. Un utente malintenzionato può manipolare l'input in modo tale da far sì che la coda dei dati venga scritta all'esterno del buffer allocato. Si noti che, nonostante la complessità dello sfruttamento della vulnerabilità, non è escluso che il problema venga portato all'esecuzione del codice.
La correzione è stata pubblicata come patch. Lo stato di eliminazione delle vulnerabilità nelle distribuzioni può essere valutato in queste pagine: Ubuntu, SUSE, RHEL, Fedora, Debian. Per risolvere i problemi in GRUB2, non è sufficiente aggiornare solo il pacchetto; sarà necessario anche generare nuove firme digitali interne e aggiornare programmi di installazione, bootloader, pacchetti kernel, firmware fwupd e livello shim.
La maggior parte delle distribuzioni Linux utilizza un piccolo livello shim firmato digitalmente da Microsoft per l'avvio verificato in modalità UEFI Secure Boot. 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.
Per bloccare la vulnerabilità senza revocare la firma digitale, le distribuzioni possono utilizzare il meccanismo SBAT (UEFI Secure Boot Advanced Targeting), supportato per GRUB2, shim e fwupd nelle distribuzioni Linux più popolari. SBAT è stato sviluppato in collaborazione con Microsoft e prevede l'aggiunta di metadati aggiuntivi ai file eseguibili dei componenti UEFI, che includono informazioni su produttore, prodotto, componente e versione. I metadati specificati sono certificati con una firma digitale e possono essere inclusi separatamente negli elenchi dei componenti consentiti o vietati per UEFI Secure Boot.
SBAT consente di bloccare l'uso delle firme digitali per i numeri di versione dei singoli componenti senza dover revocare le chiavi per Secure Boot. Il blocco delle vulnerabilità tramite SBAT non richiede l'uso di un elenco di revoche di certificati UEFI (dbx), ma viene eseguito a livello di sostituzione della chiave interna per generare firme e aggiornare GRUB2, shim e altri artefatti di avvio forniti dalle distribuzioni. Prima dell'introduzione di SBAT, l'aggiornamento dell'elenco di revoche di certificati (dbx, UEFI Revocation List) era un prerequisito per bloccare completamente la vulnerabilità, poiché un utente malintenzionato, indipendentemente dal sistema operativo utilizzato, poteva utilizzare supporti di avvio con una vecchia versione vulnerabile di GRUB2, certificato da una firma digitale, per compromettere UEFI Secure Boot.
Fonte: opennet.ru