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à 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à 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à in GRUB.
Di seguito è riportata la traduzione della nota di Garrett:
Quando è stata sviluppata la specifica UEFI Secure Boot, tutti i partecipanti erano, per così dire, un po' naïf. Il modello principale di sicurezza di Secure Boot implica che tutto il codice 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 fidato per imporre qualsiasi altra politica di sicurezza che desideriamo. È 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 non affidabile in una variabile e poi rifiutare di caricare qualsiasi cosa con quell'hash, anche se firmato da una chiave affidabile.
Sfortunatamente, si è scoperto che il problema è 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à, è 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 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ì 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.
La soluzione è 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 una vulnerabilità viene scoperta e risolta, questa generazione viene incrementata. Può poi essere rilasciato un aggiornamento che definisce la generazione minima — i componenti di avvio controlleranno il prossimo elemento nella catena, confronteranno il suo nome e numero di generazione con quelli memorizzati nella variabile di firmware e decideranno se eseguirlo o meno, in base a ciò. Invece di revocare un gran numero di hash singoli, può essere rilasciato un solo aggiornamento che afferma: «Qualsiasi versione di GRUB con una generazione di sicurezza inferiore a questo numero è considerata non affidabile».
Perché è diventato così rilevante? SBAT è stato sviluppato congiuntamente dalla comunità 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 è stato fatto perché queste versioni di GRUB avevano vulnerabilità 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à nel bootloader di Windows, ma la vulnerabilità in GRUB era altrettanto efficace). Se lo si guarda puramente da un punto di vista della sicurezza, è un desiderio del tutto legittimo.
Ora riguardo al messaggio "Qualcosa è andato completamente storto" e all'impossibilità di avvio a seguito di questo aggiornamento. È generato da shim, e non da alcun codice di Microsoft. Shim tiene conto degli aggiornamenti SBAT, e per non violare i principi di sicurezza accettati da altri bootloader nel sistema, e, anche se Microsoft ha rilasciato un aggiornamento SBAT, è proprio il bootloader Linux che alla fine si rifiuta di avviare le versioni più vecchie di GRUB. Tutto funziona come dovrebbe.
Il problema che le persone hanno riscontrato è che diverse distribuzioni Linux non hanno rilasciato versioni di GRUB con una generazione di sicurezza più recente, e pertanto queste versioni di GRUB sono considerate insicure (è importante sottolineare che GRUB è firmato dalle stesse distribuzioni, non da Microsoft, quindi non c'è 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 è 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.
Qual è il risultato finale? Microsoft (per ragioni ovvie) non voleva che Windows potesse essere attaccato tramite una versione vulnerabile di GRUB, che avrebbe potuto essere ingannata per eseguire codice arbitrario e poi introdurre un bootkit nel kernel di Windows durante l'avvio. Microsoft ha affrontato il problema rilasciando un aggiornamento di Windows che ha aggiornato la variabile SBAT, specificando che le versioni vulnerabili di GRUB non dovevano essere caricate su questi sistemi. Il bootloader di primo livello fornito dal distributore leggeva questa variabile, leggeva la partizione SBAT dalla copia installata di GRUB, capiva che c'erano conflitti e si rifiutava di caricare grub con un messaggio «Qualcosa è andato completamente storto». Questo aggiornamento non avrebbe dovuto applicarsi ai sistemi con avvio doppio, ma è stato comunque applicato.
In sintesi:
1) Microsoft ha applicato l'aggiornamento a sistemi su cui non avrebbe dovuto applicarsi
2) Alcuni distribuzioni Linux non hanno aggiornato il bootloader GRUB e la generazione della sicurezza SBAT quando sono state trovate vulnerabilità in GRUB.
Di conseguenza, alcune persone non riescono a caricare i propri sistemi. Penso che ci siano molte responsabilità qui. Microsoft avrebbe dovuto condurre più 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é altrimenti forniscono un vettore di attacco che può essere utilizzato per compromettere altri sistemi operativi, e questo è una sorta di violazione del contratto sociale attorno a tutto ciò.
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, è anche qualcosa di cui non vuoi renderti conto dopo eventi del genere. Pertanto, comprendo il motivo per cui è attivato di default; perciò 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.
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 è 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 è colpa tua. Mi scuso.
Fonte: opennet.ru
