Hanno rilevato due vulnerabilità in GRUB2

Sono stati divulgati i dettagli di due vulnerabilità nel boot loader GRUB2 che ppotrebbe portare all'esecuzione di codice quando si utilizzano caratteri appositamente progettati e si gestiscono determinate sequenze Unicode.

Si dice che le vulnerabilità rilevate lo sianoe può essere utilizzato per bypassare il meccanismo di avvio verificato UEFI Secure Boot. Le vulnerabilità in GRUB2 consentono l'esecuzione del codice nella fase successiva alla corretta verifica dello shim, ma prima che il sistema operativo venga caricato, interrompendo la catena di attendibilità con la modalità Secure Boot attiva e ottenendo il pieno controllo sul processo post-avvio, ad esempio, per avviare un altro sistema operativo, modificare i componenti del sistema operativo e bypassare la protezione del blocco.

Per quanto riguarda le vulnerabilità identificate, si segnala quanto segue:

• CVE-2022-2601: un overflow del buffer nella funzione grub_font_construct_glyph() durante l'elaborazione di caratteri appositamente predisposti in formato pf2, che si verifica a causa di un calcolo errato del parametro max_glyph_size e dell'allocazione di un'area di memoria che è ovviamente più piccola di quella necessaria per posizionare i glifi.
• CVE-2022-3775: Scrittura fuori limite durante il rendering di alcune stringhe Unicode in un carattere personalizzato. Il problema è presente nel codice di gestione 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ò raccogliere input in modo tale da causare la scrittura di una coda di dati dal buffer allocato. Si noti che, nonostante la complessità dello sfruttamento della vulnerabilità, non è esclusa l'esposizione del problema all'esecuzione di codice.

La mitigazione completa contro tutti i CVE richiederà correzioni aggiornate con l'ultimo SBAT (Secure Boot Advanced Targeting) e dati forniti da distribuzioni e fornitori.
Questa volta l'elenco di revoche UEFI (dbx) non verrà utilizzato e la revoca di quelli non funzionanti
i manufatti saranno realizzati solo con SBAT. Per informazioni su come applicare il
ultime revoche SBAT, vedere mokutil(1). Le correzioni del fornitore possono esplicitamente consentire l'avvio di artefatti di avvio noti meno recenti.

GRUB2, shim e altri artefatti di avvio di tutti i fornitori interessati verranno aggiornati. sarà disponibile quando l'embargo verrà revocato o qualche tempo dopo.

Si fa menzione di ciò la maggior parte delle distribuzioni Linux utilizza un piccolo livello di patch, 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 distribuzione di non certificare tutti gli aggiornamenti del kernel e di GRUB con Microsoft.

Per bloccare la vulnerabilità senza revoca della firma digitale, distribuzioni può utilizzare il meccanismo SBAT (UEFI Secure Boot Advanced Targeting), supportato da GRUB2, shim e fwupd sulle distribuzioni Linux più diffuse.

SBAT è stato sviluppato in collaborazione con Microsoft e comporta l'aggiunta di ulteriori metadati ai file eseguibili del componente UEFI, incluse informazioni su produttore, prodotto, componente e versione. I metadati specificati sono firmati digitalmente e possono essere inclusi in elenchi separati di componenti consentiti o vietati per UEFI Secure Boot.

SBAT consente di bloccare l'uso di una firma digitale per i singoli numeri di versione dei componenti senza la necessità di revocare le chiavi per l'avvio protetto. Il blocco delle vulnerabilità tramite SBAT non richiede l'uso di un UEFI CRL (dbx), ma piuttosto 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 revoca dei 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 versione vulnerabile precedente di GRUB2 certificato da una firma digitale per compromettere UEFI Secure Boot.

Infine Vale la pena ricordare che la correzione è stata rilasciata come patch., per risolvere i problemi in GRUB2, non è sufficiente aggiornare il pacchetto, sarà necessario anche creare nuove firme digitali interne e aggiornare gli installer, i bootloader, i pacchetti del kernel, fwupd-firmware e shim-layer.

Lo stato di correzione della vulnerabilità nelle distribuzioni può essere valutato in queste pagine: Ubuntu, SUSE, RHEL, Fedora y Debian.

Puoi controllare di più al riguardo nel seguente link