Matthew Garrett, noto sviluppatore del kernel Linux, che ha ricevuto un premio dalla Free Software Foundation per il suo contributo allo sviluppo del software libero, ha discusso del meccanismo SBAT (Secure Boot Advanced Targeting), progettato per bloccare le vulnerabilit\u00e0 nel bootloader senza revocare la firma digitale, e del suo ruolo nel recente incidente relativo a un aggiornamento di Windows che ha comportato l'impossibilit\u00e0 di avviare alcune distribuzioni Linux installate in parallelo a Windows su sistemi con UEFI Secure Boot attivato. In breve, le colpe ricadono sia su Microsoft, che non ha testato adeguatamente l'aggiornamento e lo ha applicato a sistemi non idonei, sia sugli sviluppatori di alcune distribuzioni Linux, che non hanno aggiornato il bootloader GRUB e il numero di versione SBAT quando sono state rilevate vulnerabilit\u00e0 in GRUB. <\/p>\n
Di seguito \u00e8 riportata la traduzione della nota di Garrett: <\/p>\n
\nQuando \u00e8 stata sviluppata la specifica UEFI Secure Boot, tutti i partecipanti erano, diciamo, un po' naive. Il modello di sicurezza principale di Secure Boot consiste nel fatto che tutto il codice che viene eseguito in un ambiente privilegiato a livello di kernel deve essere verificato prima dell'esecuzione \u2014 il firmware verifica il bootloader, il bootloader verifica il kernel, e il kernel verifica qualsiasi codice caricato successivamente. Cos\u00ec abbiamo un ambiente di fiducia per imporre qualsiasi altra politica di sicurezza desideriamo. \u00c8 ovvio che le persone possono commettere errori, ma nella specifica era previsto un modo per revocare i componenti firmati che si sono rivelati inaffidabili: basta aggiungere l'hash del codice inaffidabile a una variabile e poi rifiutare di caricare qualsiasi cosa con quell'hash, anche se firmata con una chiave fidata. <\/p>\n
Sfortunatamente, si \u00e8 scoperto che il problema \u00e8 su larga scala. Ogni distribuzione Linux che opera nell'ecosistema Secure Boot genera i propri file binari di avvio, e ognuno di essi ha il proprio hash. Se nel codice sorgente di un bootloader viene trovata una vulnerabilit\u00e0, \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 un nuovo set di hash ogni volta che si scopre che GRUB (il bootloader originariamente scritto in un'epoca in cui non si praticava la protezione dell'avvio, e che ha diversi parser di immagini img, cos\u00ec come un parser di font) ha un altro meccanismo che permette a un attaccante di costringerlo a eseguire codice arbitrario, quindi era necessaria un'altra soluzione. <\/p>\n
Questa soluzione \u00e8 stata chiamata 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 viene individuata e risolta una vulnerabilit\u00e0, questa generazione aumenta. Pu\u00f2 quindi essere rilasciato un aggiornamento che definisce la generazione minima \u2014 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, in base a questo. Invece di revocare un gran numero di singoli hash, pu\u00f2 essere rilasciato un unico aggiornamento che dice semplicemente: \u00abQualsiasi versione di GRUB con una generazione di sicurezza inferiore a questo numero \u00e8 considerata non affidabile\u00bb. <\/p>\n
Perch\u00e9 \u00e8 diventato cos\u00ec rilevante? SBAT \u00e8 stato sviluppato congiuntamente dalla comunit\u00e0 Linux e Microsoft, e Microsoft ha deciso di rilasciare un aggiornamento per Windows che avvisava 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 avevano vulnerabilit\u00e0 di sicurezza reali che consentivano agli aggressori di compromettere la catena di avvio sicuro di Windows, e abbiamo visto esempi concreti di malware che miravano a 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 da un punto di vista della sicurezza, \u00e8 un desiderio del tutto legittimo. <\/p>\n
Ora, riguardo al messaggio \u00abQualcosa \u00e8 andato storto\u00bb e all'impossibilit\u00e0 di avviarsi a causa di questo aggiornamento. \u00c8 emesso da shim, non da qualche codice di Microsoft. Shim tiene conto degli aggiornamenti SBAT e, per non compromettere i principi di sicurezza adottati da altri bootloader nel sistema, e sebbene Microsoft abbia rilasciato un aggiornamento SBAT, \u00e8 il bootloader Linux a rifiutare di avviare le versioni precedenti di GRUB. Tutto funziona come dovrebbe. <\/p>\n
Il problema che le persone hanno riscontrato \u00e8 che diverse distribuzioni Linux non hanno rilasciato versioni di GRUB con una generazione di sicurezza pi\u00f9 recente, e pertanto queste versioni di GRUB sono considerate insicure (\u00e8 importante sottolineare che GRUB \u00e8 firmato dalle stesse distribuzioni, non da Microsoft, quindi non c'\u00e8 alcun ritardo esterno). Secondo Microsoft, l'aggiornamento di Windows Update avrebbe dovuto applicare l'aggiornamento SBAT solo ai sistemi che eseguono esclusivamente Windows, mentre qualsiasi installazione con avvio duale sarebbe rimasta vulnerabile a attacchi fino a quando la distribuzione installata non avrebbe aggiornato GRUB e non avrebbe aggiornato la generazione SBAT. Sfortunatamente, come ora \u00e8 chiaro, questo non ha funzionato come previsto, e almeno alcuni sistemi con avvio duale hanno applicato l'aggiornamento, mentre il Shim di quella distribuzione ha rifiutato di caricare GRUB di quella distribuzione. <\/p>\n
Qual \u00e8 il punto finale? Microsoft (per motivi ovvi) non voleva che Windows fosse attaccato tramite una versione vulnerabile di GRUB, che poteva essere indotta a eseguire codice arbitrario e quindi installare un rootkit nel kernel di Windows durante l'avvio. Microsoft ha fatto questo rilasciando un aggiornamento di Windows, che ha aggiornato la variabile SBAT, specificando che le versioni vulnerabili di GRUB non dovevano essere avviate su quei sistemi. Il bootloader di prima fase fornito dalla distribuzione Shim leggeva questa variabile, leggeva la sezione SBAT dalla copia installata di GRUB, capiva che c'erano conflitti e rifiutava di avviare grub con il messaggio \u00abQualcosa \u00e8 andato storto\u00bb. Questo aggiornamento non avrebbe dovuto essere applicato ai sistemi a doppio avvio, ma \u00e8 stato comunque applicato. <\/p>\n
In sintesi: <\/p>\n
1) Microsoft ha applicato l'aggiornamento a sistemi su cui non avrebbe dovuto applicarsi <\/p>\n
2) Alcuni distribuzioni Linux non hanno aggiornato il bootloader GRUB e la generazione della sicurezza SBAT quando sono state trovate vulnerabilit\u00e0 in GRUB. <\/p>\n
Di conseguenza, alcune persone non riescono a caricare i propri sistemi. Penso che ci siano molte responsabilit\u00e0 qui. Microsoft avrebbe dovuto condurre pi\u00f9 test per assicurarsi che le installazioni con avvio multiplo possano essere identificate correttamente. Ma anche le distribuzioni che forniscono bootloader firmati devono garantire che vengano aggiornati e che la generazione di sicurezza sia aggiornata, perch\u00e9 altrimenti forniscono un vettore di attacco che pu\u00f2 essere utilizzato per compromettere altri sistemi operativi, e questo \u00e8 una sorta di violazione del contratto sociale attorno a tutto ci\u00f2. <\/p>\n
Purtroppo, qui le vittime sono principalmente gli utenti finali, che si trovano di fronte al problema che il sistema smette improvvisamente di caricare il sistema operativo che desiderano avviare. Questo non dovrebbe mai succedere. Non penso che un sondaggio tra gli utenti finali su se vogliono aggiornamenti del sistema di avvio sicuro porterebbe a buoni risultati, e sebbene mi pieghi vagamente a pensare che l'avvio sicuro UEFI non sia qualcosa che porti vantaggi alla maggior parte degli utenti finali, \u00e8 anche qualcosa di cui non vuoi renderti conto dopo eventi del genere. Pertanto, comprendo il motivo per cui \u00e8 attivato di default; perci\u00f2 sostengo la sua attivazione predefinita e condivido la scelta di Microsoft, tranne per il tentativo fallito di evitare l'aggiornamento su sistemi con doppio avvio. <\/p>\n
In ogni caso, sono stato molto coinvolto nell'implementazione di questo meccanismo per Linux nel 2012 e ho scritto il primo prototipo di Shim (che ora \u00e8 un bootloader significativamente migliore, supportato da un numero maggiore di persone, e che non tocco da diversi anni), quindi se vuoi incolpare qualcuno, per favore non esitare a incolpare me. Questo non avrebbe dovuto accadere, e se non sei Microsoft o una distribuzione Linux, non \u00e8 colpa tua. Mi scuso. <\/p><\/blockquote>\n