Matthew Garrett spiega chi è responsabile del crash del dual boot!
Circa 2 settimane fa ho scritto circa il problema causato da un aggiornamento Microsoft sui sistemi dual boot con le distribuzioni GNU/Linux che utilizzano GRUB, che invito a rileggere per tutti i dettagli, ed ora, con questo aggiornamento, scopriamo il vero responsabile del problema …
Alcuni giorni dopo l’evento, Matthew Garrett, un rinomato sviluppatore del kernel Linux, ha pubblicato una nota in cui spiegava il funzionamento del meccanismo SBAT (Secure Boot Advanced Targeting). Garrett ha spiegato che SBAT è stato progettato per bloccare le vulnerabilità nel bootloader senza la necessità di revocare le firme digitali. Questo meccanismo è stato centrale nel recente incidente causato da un aggiornamento di Windows che ha colpito alcune distribuzioni GNU/Linux su sistemi con avvio sicuro UEFI, impedendone l’avvio.
Secondo Garrett, sia Microsoft che alcuni sviluppatori Linux sono corresponsabili del problema: Microsoft per non aver testato adeguatamente l’aggiornamento in tutti gli scenari, e gli sviluppatori Linux per non aver aggiornato il numero di versione di sicurezza di GRUB e SBAT quando sono state scoperte vulnerabilità in GRUB.
Garrett afferma inoltre che, quando è stata creata la specifica UEFI Secure Boot, tutti i soggetti coinvolti hanno sottovalutato la complessità del sistema. Il modello di sicurezza di Secure Boot afferma che tutto il codice 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 e il kernel verifica qualsiasi codice aggiuntivo caricato in fase di runtime. Questo crea un ambiente sicuro per applicare ulteriori politiche di sicurezza.
Inoltre, la specifica prevede un meccanismo per revocare i componenti firmati non attendibili: l’hash del codice problematico viene aggiunto a una variabile, impedendo il caricamento di qualsiasi codice con quell’hash, anche se firmato con una chiave attendibile.
Fino a questo punto tutto sembra a posto, ma Garrett afferma che il problema risiede nella portata e nella frammentazione dell’ecosistema Secure Boot. Ogni distribuzione genera i propri binari per il bootloader, ciascuno con il proprio hash. Quando viene rilevata una vulnerabilità nel codice sorgente di un bootloader, è necessario revocare un gran numero di file binari diversi. Inoltre, la memoria disponibile per archiviare una variabile contenente tutti questi hash è limitata, e non c’è abbastanza spazio per aggiungere un nuovo set di hash ogni volta che viene scoperta una vulnerabilità in GRUB. Per questo motivo era necessaria una soluzione diversa.
Quella soluzione era SBAT.
Il concetto di SBAT è relativamente semplice: ogni componente critico all’interno della catena di avvio dichiara un numero di generazione di sicurezza incluso nel file binario firmato. Quando una vulnerabilità viene identificata e risolta, questo numero di generazione aumenta. Da lì è possibile emettere un aggiornamento che stabilisce la generazione minima accettabile. I componenti di avvio controlleranno questo numero per determinare se possono eseguire l’elemento successivo nella catena di avvio, confrontando il nome e il numero di build con i valori memorizzati nella variabile del firmware.
Invece di dover revocare numerosi hash individuali, un singolo aggiornamento può dire: “Qualsiasi versione di GRUB con una generazione di sicurezza inferiore a questo numero è considerata non attendibile”.
Linux, il vero responsabile
Garrett afferma che l’errore che impedisce ad alcuni sistemi di avviarsi dopo l’aggiornamento non proviene dal codice Microsoft, ma dal componente shim del bootloader di Linux. Shim è un piccolo programma che funge da intermediario tra il firmware UEFI e il bootloader, come GRUB. Il suo scopo principale è quello di verificare le firme digitali dei componenti di avvio per garantire che siano sicuri. Sebbene Microsoft abbia rilasciato l’aggiornamento SBAT, è il bootloader di Linux, tramite shim, che si rifiuta di eseguire le versioni precedenti di GRUB, facendo funzionare tutto come previsto dal punto di vista tecnico.
Il vero problema sta nel fatto che diverse distribuzioni GNU/Linux non hanno rilasciato versioni aggiornate di GRUB che incorporino correzioni di sicurezza e nuove generazioni di SBAT. Ciò fa sì che queste versioni di GRUB siano considerate non sicure, poiché shim ne blocca l’esecuzione.
E qui Garrett sottolinea una cosa importante ovvero che GRUB è firmato dalle stesse distribuzioni GNU/Linux, non da Microsoft, il che elimina eventuali ritardi esterni nell’aggiornamento.
Quindi correttamente, Garrett accenna che Microsoft ha rilasciato il suo aggiornamento da applicare solo su Windows (come dovrebbe essere) e il problema era dovuto alle distribuzioni GNU/Linux che gestivano ancora versioni vulnerabili e generavano il problema con il dual boot.
Infine, Garrett menziona che, purtroppo, le principali vittime di questa situazione sono gli utenti finali, che improvvisamente si trovano impossibilitati ad avviare il sistema operativo desiderato. Questo è un problema che non dovrebbe mai verificarsi. Sebbene sia comprensibile la necessità di abilitare UEFI Secure Boot per impostazione predefinita, e la decisione di Microsoft in tal senso sia generalmente supportata, è evidente che il tentativo di impedire l’aggiornamento sui sistemi dual-boot non ha funzionato come previsto. Questo ha causato notevoli disagi agli utenti, che si sono trovati a dover affrontare problemi tecnici complessi senza preavviso.
Se sei interessati a saperne di più , puoi leggere la nota originale di Matthew Garrett al seguente link.
Fonte: https://mjg59.dreamwidth.org/70348.html
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
