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\u00e0 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\u00e0 di avviare alcune distribuzioni Linux installate in parallelo con Windows su sistemi con UEFI Secure Boot attivo. In sintesi, la colpa \u00e8 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\u00e0 in GRUB. <\/p>\n
Di seguito la traduzione delle osservazioni di Garrett: <\/p>\n
\nQuando \u00e8 stata sviluppata la specifica UEFI Secure Boot, tutti i partecipanti erano, diciamo, un po' naif. Il modello di sicurezza principale di Secure Boot \u00e8 che tutto il codice che viene eseguito in un ambiente privilegiato a livello di kernel deve essere verificato prima dell'esecuzione: il firmware verifica il bootloader, il bootloader verifica il kernel, il kernel verifica qualsiasi codice aggiuntivo caricato in fase di esecuzione, e ora abbiamo un ambiente affidabile per applicare qualsiasi altra politica di sicurezza che desideriamo. \u00c8 ovvio che le persone possono sbagliarsi, ma nella specifica \u00e8 stato previsto un modo per revocare i componenti firmati che si sono rivelati non affidabili: basta aggiungere l'hash del codice inaffidabile a una variabile e poi rifiutarsi di caricare qualsiasi cosa con quell'hash, anche se firmato da una chiave fidata. <\/p>\n
Sfortunatamente, come si \u00e8 scoperto, il problema \u00e8 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\u00e0 nel codice sorgente di tale bootloader, \u00e8 necessario revocare un gran numero di diversi file binari. E la memoria disponibile per memorizzare la variabile contenente tutti questi hash \u00e8 limitata. Non ci sar\u00e0 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 \u00e8 stata necessaria un'altra soluzione. <\/p>\n
La soluzione a questo problema \u00e8 stata SBAT. Il concetto generale di SBAT \u00e8 piuttosto semplice. Ogni componente importante nella catena di avvio dichiara una generazione di sicurezza, che viene inclusa nel file binario firmato. Quando una vulnerabilit\u00e0 viene scoperta e risolta, questa generazione aumenta. Possono quindi essere rilasciati aggiornamenti che definiscono la generazione minima: i componenti di avvio guarderanno al prossimo elemento nella catena, confronteranno il suo nome e numero di generazione con quelli memorizzati nella variabile del firmware e decideranno se eseguirlo o meno, basandosi su questo. Anzich\u00e9 revocare un gran numero di singoli hash, \u00e8 possibile rilasciare un solo aggiornamento che semplicemente dice: 'Qualsiasi versione di GRUB con una generazione di sicurezza inferiore a questo numero \u00e8 considerata non affidabile'. <\/p>\n
Perch\u00e9 improvvisamente questo \u00e8 diventato rilevante? SBAT \u00e8 stato sviluppato in collaborazione tra la comunit\u00e0 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 \u00e8 stato fatto perch\u00e9 queste versioni di GRUB presentavano reali vulnerabilit\u00e0 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\u00e0 nel bootloader di Windows, ma la vulnerabilit\u00e0 in GRUB era altrettanto efficace). Se lo si guarda puramente dal punto di vista della sicurezza, \u00e8 un desiderio del tutto legittimo. <\/p>\n
Ora, per quanto riguarda il messaggio 'Qualcosa \u00e8 andato storto' e l'impossibilit\u00e0 di avviarsi a causa di questo aggiornamento. Questo messaggio \u00e8 generato da shim, non da alcun codice di Microsoft. Shim tiene conto degli aggiornamenti SBAT, e per non violare i principi di sicurezza adottati da altri bootloader nel sistema, anche se Microsoft ha rilasciato un aggiornamento SBAT, \u00e8 proprio il bootloader Linux che, di conseguenza, si rifiuta di avviare le vecchie versioni di GRUB. Tutto funziona come dovrebbe. <\/p>\n
Il problema con cui le persone si sono confrontate \u00e8 che diversi distributori Linux non hanno rilasciato versioni di GRUB con una generazione di sicurezza pi\u00f9 recente, e quindi queste versioni di GRUB sono considerate non sicure (\u00e8 importante notare che GRUB \u00e8 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 \u00e8 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. <\/p>\n
Qual \u00e8 il risultato? Microsoft (per ovvi motivi) non voleva che Windows fosse vulnerabile ad attacchi tramite una versione vulnerabile di GRUB, che poteva essere ingannata per eseguire codice arbitrario e poi infiltrarsi 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 dovevano essere caricate su questi sistemi. Il bootloader di primo livello fornito dalla distribuzione Shim leggeva questa variabile, controllava la sezione SBAT dalla copia installata di GRUB, capiva che c'era un conflitto e si rifiutava di caricare grub con il messaggio \"Qualcosa \u00e8 andato completamente storto\". Questo aggiornamento non avrebbe dovuto essere applicato ai sistemi con dual boot, ma \u00e8 stato comunque applicato. <\/p>\n
In sintesi: <\/p>\n
1) Microsoft ha applicato l'aggiornamento a sistemi a cui non avrebbe dovuto applicarsi <\/p>\n
2) Alcuni distributori Linux non hanno aggiornato il bootloader GRUB e la generazione di sicurezza SBAT quando sono state scoperte vulnerabilit\u00e0 in GRUB. <\/p>\n
Come risultato, alcune persone non possono caricare i propri sistemi. Penso che ci siano molte responsabilit\u00e0 qui. Microsoft dovrebbe condurre pi\u00f9 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 \u00e8 una sorta di violazione del contratto sociale che circonda tutto ci\u00f2. <\/p>\n
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\u00e0 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, \u00e8 anche una cosa che non vuoi scoprire dopo eventi del genere, quindi capisco perch\u00e9 \u00e8 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. <\/p>\n
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 \u00e8 un loader notevolmente migliore, supportato da un pubblico pi\u00f9 ampio, e al quale non ho pi\u00f9 messo mano da anni), quindi se vuoi incolpare qualcuno, per favore non esitare a incolpare me. Questo \u00e8 qualcosa che non avrebbe dovuto succedere, e se non sei Microsoft o una distribuzione di Linux, non \u00e8 colpa tua. Mi scuso. <\/p><\/blockquote>\n