Vulnerabilità UEFI SecureBoot con GRUB2 - 2021

Dopo l'annuncio fatto a Luglio 2020 del gruppo di bug BootHole in GRUB2, i ricercatori sulla sicurezza e gli sviluppatori di Debian e di altre parti hanno continuato a cercare altri problemi che potrebbero permettere di aggirare il Secure Boot di UEFI. Consultare il bollettino di sicurezza Debian 4867-1 per tutti i dettagli. Lo scopo di questo documento è spiegare le conseguenze di queste vulnerabilità della sicurezza e i passi fatti per affrontarle.

Premessa: Cos'è UEFI Secure Boot?

Lo UEFI Secure Boot (SB) è un meccanismo di verifica che assicura che il codice eseguito da un computer con firmware UEFI sia attendibile. È progettato per proteggere un sistema dal caricamento e dall'esecuzione di codice malevolo nelle prime fasi del processo di avvio, prima che sia caricato il sistema operativo.

SB funziona utilizzando somme di controllo e firme crittografiche. Ogni programma che viene caricato dal firmware contiene una firma e una somma di controllo, prima che ne sia concessa l'esecuzione il firmware controlla che il programma sia attendibile validandone la somma di controllo e la firma. Quando su un sistema è attivo il SB è impedito qualunque tentativo di eseguire un programma non attendibile. Ciò impedisce di eseguire codice inaspettato / non autorizzato nell'ambiente UEFI.

La gran parte dell'hardware x86 viene precaricato dal costruttore con le chiavi di Microsoft. Ciò comporta che il firmware di tali sistemi riterrà attendibile i binari firmati da Microsoft. I sistemi più recenti sono consegnati con il SB attivato, con le impostazioni predefinite non sono in grado di eseguire codice non firmato tuttavia è possibile cambiare la configurazione del firmware e disattivare il SB oppure registrare delle chiavi di firma aggiuntive.

Debian, come molti altri sistemi operativi basati su Linux, utilizza un programma chiamato shim per ampliare la fiducia del firmware agli altri programmi che devono essere sicuri nella prima fase dell'avvio: il bootloader GRUB2, il kernel Linux e gli strumenti per l'aggiornamento del firmware (fwupd e fwupdate).

Trovati dei bug in GRUB2

È stato trovato un bug nel modulo acpi di GRUB2. Questo modulo fornisce un driver/interfaccia con ACPI (Advanced Configuration Power Interface), un componente molto comune nell'hardware dei moderni computer. Sfortunatamente il modulo ACPI attualmente consente a un utente privilegiato di caricare delle tabelle ACPI manipolate in Secure Boot e fare delle modifiche arbitrarie allo stato del sistema; questo permette facilmente di spezzare la catena di Secure Boot. Questa falla della sicurezza è stata risolta.

Come per BootHole, anziché semplicemente correggere il bug, gli sviluppatori sono stati spinti a fare un'accurata revisione del codice sorgente di GRUB2. Sarebbe stato irresponsabile correggere una falla senza cercarne altre! Sono stati trovati alcuni posti in cui, con un input inaspettato, le allocazioni di memoria interna potevano andare in overflow, in qualche altro posto la memoria avrebbe potuto essere utilizzata dopo che era stata liberata. Tutte le correzioni sono state condivise e testate dalla comunità.

Nuovamente, consultare il bollettino di sicurezza Debian 4867-1 per l'elenco completo dei problemi trovati.

È necessario revocare le chiavi per riparare la catena di Secure Boot

Debian e gli altri produttori di sistemi operativi ovviamente rilasceranno le versioni corrette di GRUB2 e Linux. Tuttavia ciò non è una soluzione completa a tutti i problemi visti. Dei malintenzionati potrebbero essere ancora in grado di usare le vecchie e vulnerabili versioni per aggirare il Secure Boot.

Per impedire ciò, il prossimo passo sarà per Microsoft di bloccare i binari non sicuri in modo da impedirne l'esecuzione con SB. Questo si ottiene utilizzando l'elenco DBX, una funzionalità prevista nel modello di UEFI Secure Boot. A tutte le distribuzioni che contengono una copia di shim firmata con le Microsoft è richiesto di fornire i dettagli dei binari o delle chiavi coinvolte per facilitare questa procedura. Nella lista di revoca UEFI verranno inserite queste informazioni. In un momento futuro, non ancora stabilito, i sistemi inizieranno a utilizzare la lista aggiornata e rifiuteranno di eseguire i binari vulnerabili con Secure Boot.

Il momento esatto in cui questo cambiamento verrà distribuito non è ancora chiaro; a un certo punto i produttori di BIOS/UEFI includeranno la nuova lista di revoca nelle nuove realizzazioni di firmware per il nuovo hardware. Microsoft potrebbe anche rilasciare aggiornamenti per i sistemi esistenti tramite Windows Update. Alcune distribuzioni Linux potrebbero rilasciare aggiornamenti tramite il proprio processo per gli aggiornamenti di sicurezza. Debian per adesso non lo fa, ma lo stiamo valutando per il futuro.

Quali sono gli effetti della revoca della chiave?

Molti produttori sono cauti sull'applicazione automatica degli aggiornamenti che revocano le chiavi usate nel Secure Boot. Le installazioni esistenti con SB attivo potrebbero immediatamente e assolutamente rifiutare l'avvio a meno che l'utente sia stato attento e abbia installato anche tutti gli aggiornamenti ai programmi. I sistemi con doppio avvio Windows/Linux potrebbero improvvisamente nono avviare più Linux. I vecchi supporti per l'installazione o di sistemi live naturalmente non riusciranno a partire, potenzialmente facendo diventare più difficile il ripristino di un sistema.

Ci sono due modi ovvi per rimediare a un sistema che non si avvia:

Entrambe le soluzioni sembrano semplici ma ciascuna potrebbe richiedere molto tempo agli utenti che hanno più sistemi. Inoltre prestare attenzione al fatto che per attivare e disattivare il Secure Boot è necessario l'accesso diretto alla macchina, normalmente non è possibile cambiare questa configurazione al di fuori del firmware del computer. Proprio per questo motivo le macchine server remote richiedono una particolare attenzione.

Per queste ragioni si raccomanda caldamente a tutti gli utenti Debian di prestare particolare attenzione a installare tutti gli aggiornamenti raccomandati per i propri sistemi il prima possibile per ridurre la possibilità di avere problemi in futuro.

Pacchetti e chiavi aggiornati

Nota: i sistemi con Debian 9 (stretch) oppure una versione più vecchia non riceveranno obbligatoriamente un aggiornamento, perché Debian 10 (buster) è stato il primo rilascio di Debian a includere il supporto per Secure Boot di UEFI.

Sono cinque i pacchetti sorgente in Debian che sono stati aggiornati per Secure Boot di UEFI con le modifiche descritte di seguito:

1. GRUB2

Le versioni aggiornate dei pacchetti Debian GRUB2 sono adesso disponibili tramite l'archivio debian-security per il rilascio stabile Debian 10 (buster). Le versioni corrette saranno nel normale archivio delle versioni di sviluppo di Debian (unstable e testing) molto presto.

2. Linux

Le versioni aggiornate dei pacchetti Debian linux sono adesso disponibili tramite buster-proposed-updates per il rilascio stabile Debian 10 (buster) e saranno inserite nel prossimo rilascio minore 10.10. I nuovi pacchetti sono pure nell'archivio Debian delle versioni di sviluppo (unstable e testing). Ci aspettiamo che presto i pacchetti con le correzioni siano caricati in buster-backports.

3. Shim e SBAT

I bug della serie BootHole sono stati i primi per i quali è stata necessaria una revoca delle chiavi dell'ecosistema di UEFI Secure Boot su larga scala. Questa attività ha dimostrato una pecca di SB nella revoca: visto che ci sono molte distribuzioni Linux e molti binari per UEFI, la dimensione dell'elenco delle revoche cresce rapidamente. Parecchi computer hanno poco spazio per memorizzare le informazioni sulla revoca delle chiavi e questo spazio può riempirsi velocemente e danneggiare il sistema.

Per combattere questo problema, gli sviluppatori di shim hanno pensato a un modo efficiente per bloccare in futuro i binari UEFI insicuri: è stato chiamato SBAT (Secure Boot Advanced Targeting). Funziona tracciando i numeri dei programmi firmati, anziché revocare individualmente le firme a ogni problema rivelato, si usano dei contatori per indentificare le vecchie versioni dei programmi che non sono più ritenute sicure. La revoca di una vecchia serie di binari di GRUB2 (per esempio) adesso diventa semplicemente l'aggiornamento di una variabile UEFI che contiene il numero di generazione di GRUB2; qualsiasi versione di GRUB2 più vecchia di quel numero non sarà più ritenuta sicura. Per maggiori informazioni su SBAT, consultare la documentazione di shim SBAT.

Sfortunatamente, lo sviluppo di shim SBAT non è ancora pronto. Gli sviluppatori confidavano di aver già rilasciato la nuova versione di shim con questa nuova funzionalità ma sono stati riscontrati dei problemi inaspettati e lo sviluppo è in corso. Nella comunità Linux ci si aspetta di avere questa nuova versione molto presto. Fino a quando non sarà pronta, si continuerà a utilizzare i binari firmati di shim esistenti.

Le versioni aggiornate dei pacchetti Debian shim saranno disponibili non appena pronte, il loro rilascio sarà annunciato qui e da altre parti. Saranno inserite nel prossimo rilascio minore 10.10 e i nuovi pacchetti saranno anche nell'archivio Debian delle versioni di sviluppo (unstable e testing).

4. Fwupdate

Le versioni aggiornate dei pacchetti Debian fwupdate sono adesso disponibili tramite buster-proposed-updates per il rilascio stabile Debian 10 (buster) e saranno inserite nel prossimo rilascio minore 10.10. Tempo fa il pacchetto fwupdate è stato rimosso da unstable e testing in favore di fwupd.

5. Fwupd

Le versioni aggiornate dei pacchetti Debian fwupd sono adesso disponibili tramite buster-proposed-updates per il rilascio stabile Debian 10 (buster) e saranno inserite nel prossimo rilascio minore 10.10. I nuovi pacchetti sono pure nell'archivio Debian delle versioni di sviluppo (unstable e testing).

6. Chiavi

Debian ha generato delle nuove chiavi di firma e certificati per i propri pacchetti legati a Secure Boot. In passato era stato usato un solo certificato per tutti i pacchetti:

Questa volta sono state usate chiavi e certificati differenti per ciascuno dei cinque pacchetti sorgente coinvolti in modo da avere in futuro più flessibilità:

Rilascio minore Debian 10.10 (buster), aggiornamento dei supporti per l'installazione e live

Tutte le correzioni descritte sono destinate a essere inserite nel rilascio minore Debian 10.10 (buster), previsto a breve. Di conseguenza 10.10 diventa la scelta obbligata per i supporti di installazione e di sistemi live. In futuro, appena pubblicate le revoche, le immagini precedenti potrebbero non funzionare con Secure Boot.

Ulteriori informazioni

Molte altre informazioni sulla configurazione di UEFI Secure Boot in Debian sono nel Debian wiki, consultare https://wiki.debian.org/SecureBoot.

Altre risorse su questo argomento: