Matthew Garrett, noto sviluppatore del kernel Linux, che in passato ha ricevuto un premio dal Free Software Foundation per il suo contributo allo sviluppo del software libero, ha parlato del meccanismo SBAT (Secure Boot Advanced Targeting), creato per bloccare vulnerabilità nel bootloader senza revocare la firma digitale, e del suo ruolo nell'incidente recente relativo a un aggiornamento di Windows che ha portato all'impossibilità di avviare alcune distribuzioni Linux installate in parallelo con Windows su sistemi con UEFI Secure Boot attivo. In sintesi, la colpa è sia di Microsoft, che non ha testato adeguatamente l'aggiornamento applicandolo a sistemi per i quali non sarebbe dovuto essere utilizzato, sia degli sviluppatori di alcune distribuzioni Linux, che non hanno aggiornato il bootloader GRUB e il numero di versione di SBAT quando sono state scoperte vulnerabilità in GRUB.
Di seguito la traduzione delle osservazioni di Garrett:
Quando è stata sviluppata la specifica di UEFI Secure Boot, tutti i suoi partecipanti erano, diciamo, un po' naif. Il modello di sicurezza principale di Secure Boot prevede che tutto il codice che viene eseguito in un ambiente privilegiato a livello di kernel debba essere verificato prima dell'esecuzione: il firmware verifica il bootloader, il bootloader verifica il kernel, il kernel verifica qualsiasi codice aggiuntivo caricato durante l'esecuzione, e ora abbiamo un ambiente di fiducia per imporre qualsiasi altra politica di sicurezza desideriamo. È ovvio che le persone possono commettere errori, ma nella specifica c'era un modo per revocare i componenti firmati che si sono rivelati inaffidabili: basta aggiungere l'hash del codice non affidabile in una variabile e quindi rifiutare di caricare qualsiasi cosa con quell'hash, anche se è firmata con una chiave di fiducia.
Sfortunatamente, come si è scoperto, il problema è nell'ambito. Ogni distribuzione Linux che opera nell'ecosistema Secure Boot genera i propri file binari del bootloader, e ciascuno di essi ha il proprio hash. Se viene scoperta una vulnerabilità nel codice sorgente di tale bootloader, è necessario revocare un gran numero di diversi file binari. E la memoria disponibile per memorizzare la variabile contenente tutti questi hash è limitata. Non ci sarà spazio sufficiente per aggiungere ogni volta un nuovo set di hash, quando si scopre che GRUB (il bootloader originariamente scritto in un'epoca in cui non si praticava la protezione del boot e che ha diversi parser di immagini e di font) ha un altro meccanismo per consentire a un attaccante di forzarlo ad eseguire codice arbitrario, quindi è stata necessaria un'altra soluzione.
Questa soluzione è stata SBAT. Il concetto generale di SBAT è piuttosto semplice. Ogni componente importante nella catena di avvio dichiara una generazione di sicurezza che viene inclusa nel file binario firmato. Quando viene scoperta e risolta una vulnerabilità, questa generazione aumenta. Può quindi essere rilasciato un aggiornamento che definisce la generazione minima: i componenti di avvio guarderanno il prossimo elemento nella catena, confronteranno il suo nome e il numero di generazione con quelli memorizzati nella variabile del firmware e decideranno se eseguirlo o meno sulla base di queste informazioni. Invece di revocare un gran numero di singoli hash, è possibile rilasciare un'unica aggiornamento che semplicemente dice: "Qualsiasi versione di GRUB con una generazione di sicurezza inferiore a questo numero è considerata non fidata."
Perché improvvisamente questo è diventato rilevante? SBAT è stato sviluppato in collaborazione tra la comunità Linux e Microsoft, e Microsoft ha deciso di rilasciare un aggiornamento per Windows che informasse i sistemi di non fidarsi delle versioni di GRUB con una generazione di sicurezza inferiore a un certo livello. Questo è stato fatto perché queste versioni di GRUB presentavano reali vulnerabilità di sicurezza che consentivano agli aggressori di compromettere la catena di avvio sicuro di Windows, e abbiamo visto esempi concreti di malware che volevano farlo (Black Lotus ha sfruttato una vulnerabilità nel bootloader di Windows, ma la vulnerabilità in GRUB era altrettanto efficace). Se lo si guarda puramente dal punto di vista della sicurezza, è un desiderio del tutto legittimo.
Ora, per quanto riguarda il messaggio "Qualcosa è andato completamente storto" e l'impossibilità di avviare a causa di questo aggiornamento. Questo è restituito da shim e non da qualche codice di Microsoft. Shim tiene conto degli aggiornamenti SBAT e, per non violare i principi di sicurezza adottati da altri bootloader nel sistema, e benché Microsoft abbia rilasciato un aggiornamento SBAT, è il bootloader Linux che rifiuta di avviare le versioni più vecchie di GRUB per questo motivo. Tutto funziona come dovrebbe.
Il problema con cui le persone si sono confrontate è che diversi distributori Linux non hanno rilasciato versioni di GRUB con una generazione di sicurezza più recente, e quindi queste versioni di GRUB sono considerate non sicure (è importante notare che GRUB è firmato dai distributori stessi e non da Microsoft, quindi non ci sono ritardi dovuti a fattori esterni). Secondo l'intento di Microsoft, l'aggiornamento di Windows Update avrebbe dovuto applicarsi all'aggiornamento SBAT solo ai sistemi che eseguono esclusivamente Windows, mentre tutte le installazioni in dual boot sarebbero rimaste vulnerabili ad attacchi fino a quando il distributore installato non avrebbe aggiornato GRUB e non avrebbe aggiornato la generazione SBAT. Sfortunatamente, come ora è evidente, questo non ha funzionato come previsto e, almeno alcuni sistemi in dual boot hanno applicato l'aggiornamento, mentre Shim di quel distributore ha rifiutato di caricare GRUB di quel distributore.
Qual è il verdetto? Microsoft (per ragioni comprensibili) non voleva che Windows potesse essere attaccato tramite una versione vulnerabile di GRUB, che potrebbe essere ingannata per eseguire codice arbitrario e poi iniettare un bootkit nel kernel di Windows durante l'avvio. Microsoft ha fatto questo rilasciando un aggiornamento di Windows che ha aggiornato la variabile SBAT, indicando che le versioni vulnerabili di GRUB non dovrebbero avviarsi su questi sistemi. Il bootloader di primo stadio fornito dal distributore Shim leggeva questa variabile, leggeva la sezione SBAT dalla copia installata di GRUB, comprendeva che c'era un conflitto e rifiutava di avviare grub con il messaggio "Qualcosa è andato completamente storto". Questo aggiornamento non avrebbe dovuto applicarsi ai sistemi in dual boot, ma è stato comunque applicato.
In sintesi:
1) Microsoft ha applicato l'aggiornamento a sistemi a cui non avrebbe dovuto applicarsi
2) Alcuni distributori Linux non hanno aggiornato il bootloader GRUB e la generazione di sicurezza SBAT quando sono state scoperte vulnerabilità in GRUB.
Come risultato, alcune persone non possono caricare i propri sistemi. Penso che ci siano molte responsabilità qui. Microsoft dovrebbe condurre più test per assicurarsi che le installazioni con avvio multiplo possano essere identificate correttamente. Ma anche le distribuzioni che forniscono loader firmati devono assicurarsi di aggiornarli e di aggiornare le generazioni di sicurezza per conformarsi, altrimenti forniscono un vettore di attacco che potrebbe essere utilizzato per compromettere altri sistemi operativi, e questo è una sorta di violazione del contratto sociale che circonda tutto ciò.
Sfortunatamente, qui le vittime sono principalmente gli utenti finali, che si trovano ad affrontare il fatto che il sistema si rifiuta improvvisamente di caricare il sistema operativo che desiderano avviare. Questo non dovrebbe mai accadere. Non penso che un'indagine sugli utenti finali riguardo al fatto che vogliano aggiornamenti del sistema di avvio sicuro porterà a un buon risultato, e sebbene io sia vagamente incline a pensare che l'avvio sicuro UEFI non sia qualcosa che porti beneficio alla maggior parte degli utenti finali, è anche una cosa che non vuoi scoprire dopo eventi del genere, quindi capisco perché è abilitato di default, quindi supporto il fatto che sia attivato di default, e condivido la scelta di Microsoft, tranne per il tentativo fallito di evitare l'aggiornamento sui sistemi con avvio multiplo.
Ad ogni modo, sono stato fortemente coinvolto nell'implementazione di questo meccanismo per Linux nel 2012 e ho scritto il primo prototipo di Shim (che ora è un loader notevolmente migliore, supportato da un pubblico più ampio, e al quale non ho più messo mano da anni), quindi se vuoi incolpare qualcuno, per favore non esitare a incolpare me. Questo è qualcosa che non avrebbe dovuto succedere, e se non sei Microsoft o una distribuzione di Linux, non è colpa tua. Mi scuso.
Fonte: opennet.ru
