Secure Boot è attivo, ma un PC può avviare altro codice: ecco perché

Una funzione di sicurezza come Secure Boot, implementata a livello di firmware UEFI, si occupa di controllare che il software eseguito nelle prime fasi dell’avvio appartenga a una catena di fiducia autorizzata. Come ha dimostrato il ricercatore Leo Smith, però, tale catena può essere molto più ampia di quanto si immagini.

Partendo da uno shim Linux firmato da Microsoft (piccolo bootloader che fa da ponte tra UEFI Secure Boot e Linux: consente a Linux di avviarsi con Secure Boot attivo), è riuscito ad arrivare all’avvio di un ambiente personalizzato mantenendo Secure Boot abilitato. Non si tratta di una nuova vulnerabilità crittografica e neppure della “rottura” di Secure Boot: il caso mette piuttosto in evidenza quanto contino la configurazione del firmware, le chiavi considerate attendibili e l’accesso fisico alla macchina.

Secure Boot verifica la fiducia, non decide quale sistema operativo preferiamo

Secure Boot si attiva prima dell’avvio del sistema operativo: il firmware UEFI verifica le firme digitali dei componenti caricati e permette l’esecuzione se la catena porta a una chiave considerata affidabile. Abbiamo spiegato nel dettaglio il meccanismo nell’approfondimento sui certificati Secure Boot e sulle nuove CA Microsoft.

Il punto importante è che molti PC progettati per supportare anche Linux e applicazioni UEFI di terze parti includono tra le chiavi attendibili anche la Microsoft 3rd Party UEFI CA. La stessa documentazione Microsoft osserva che questa scelta allarga il perimetro di fiducia: una macchina configurata in questo modo non accetta soltanto il boot manager di Windows, ma potenzialmente anche bootloader Linux firmati tramite l’infrastruttura Microsoft.

Dopo che UEFI considera valido lo shim, quest’ultimo può verificare GRUB, kernel e altri componenti usando proprie chiavi. Supporta inoltre le Machine Owner Keys (MOK), chiavi che permettono al proprietario della macchina di aggiungere software affidabile senza modificare direttamente il database Secure Boot del firmware.

È una caratteristica legittima e molto utile: serve, per esempio, per avviare kernel personalizzati o caricare determinati moduli: la documentazione Ubuntu descrive proprio MokManager come lo strumento utilizzato per aggiungere o eliminare MOK e autorizzare componenti personalizzati.

L’esperimento di Smith sfrutta questo modello di fiducia: su una macchina che accetta la CA Microsoft per software UEFI di terze parti, un supporto esterno contenente uno shim opportunamente firmato può superare il primo controllo di Secure Boot. Facendo quindi leva sul sistema MOK, diventa possibile estendere ulteriormente ciò che la catena considera affidabile.

Non significa che chiunque possa entrare nel vostro PC

Il risultato del test condotto da Smith non dimostra affatto che Secure Boot sia inutile e non descrive un attacco remoto. Presuppone accesso fisico alla macchina nonché una configurazione firmware che permetta di avviare dispositivi esterni e consideri attendibile la CA UEFI Microsoft per software di terze parti.

Anche il comportamento di MokManager e le protezioni aggiuntive possono cambiare a seconda della distribuzione e della configurazione.

Microsoft, non a caso, spiega che i Secured-core PC possono essere configurati per non fidarsi della 3rd Party UEFI CA: in questo modo si riduce la superficie d’attacco, al prezzo di limitare la compatibilità con sistemi operativi e componenti UEFI alternativi.

Il vero problema è l’accesso fisico

Secure Boot è spesso interpretato come una sorta di lucchetto universale del PC: in realtà protegge soprattutto l’integrità della catena di avvio: cerca di impedire che un bootkit o un componente non autorizzato si inseriscano prima del sistema operativo.

Non sostituisce però le protezioni contro un attaccante che può sedersi davanti alla macchina, collegare periferiche, aprire il menu di boot o modificare impostazioni firmware lasciate senza protezione.

Per un notebook aziendale diventano quindi importanti anche la configurazione UEFI, il blocco dell’avvio da supporti esterni quando non necessario e, soprattutto, la cifratura del disco. Abbiamo già visto come Secure Boot, TPM, PCR7 e BitLocker siano strettamente collegati.

Se l’obiettivo è proteggere i dati da chi entra fisicamente in possesso del computer, Secure Boot da solo non basta. BitLocker con una configurazione adeguata (e parliamo di autenticazione pre-boot) aggiunge un confine completamente diverso: anche riuscendo ad avviare un altro sistema operativo, il contenuto dell’unità resta cifrato.

Note finali

Non ci sentiamo di sostenere in toto la tesi “Not So Secure Boot” del ricercatore: quanto descritto non dimostra un fallimento matematico delle firme digitali. Evidenzia un problema più sottile: la sicurezza di Secure Boot dipende anche da quante chiavi, CA e percorsi di avvio scegliamo di considerare attendibili.

La compatibilità ha un costo: un PC capace di avviare Windows, Linux, driver UEFI e strumenti di terze parti deve accettare un insieme di firme più ampio rispetto a una macchina rigidamente bloccata su un’unica catena di boot.

È proprio per questo che Secure Boot va considerato un componente della protezione del sistema, non un “sigillo” assoluto.