Cos'è SBAT e perché Windows ha fatto esplodere il dual boot con Linux

Il sistema Secure Boot, parte integrante del BIOS UEFI, nacque con l’idea di creare un ambiente sicuro che potesse impedire l’esecuzione di codice non autorizzato a livello del kernel del sistema operativo. Il Secure Boot prevede che ogni componente nella catena di avvio, dal firmware al bootloader fino al kernel, debba essere verificato e firmato digitalmente. Se un componente non è considerato affidabile, è bloccato e l’avvio del sistema interrotto.

Nei giorni scorsi abbiamo raccontato il problema lamentato da utenti utenti che hanno riscontrato l’impossibilità di usare il dual boot tra Linux e Windows dopo l’avvenuta applicazione delle patch di sicurezza Microsoft distribuite a ridosso di ferragosto.

Ma qual è il problema che ha fatto esplodere il dual boot con Linux? Come hanno fatto gli aggiornamenti Microsoft a causare un problema così severo all’avvio del sistema?

SBAT (Secure Boot Advanced Targeting): cos’è e perché è importante

Sviluppato come una collaborazione tra la comunità Linux e Microsoft, il progetto SBAT è stato guidato da sviluppatori che lavorano su distribuzioni Linux e su strumenti legati al boot, insieme al contributo di Microsoft. SBAT è emerso come una necessità per gestire in modo più efficiente le vulnerabilità nella catena di avvio su larga scala, unendo gli sforzi di entrambe le parti per migliorare la sicurezza del sistema.

Abbiamo già detto che quando un sistema si avvia su una macchina protetta attraverso Secure Boot, ogni componente deve essere verificato in fase di boot per garantire che sia legittimo e sicuro. Il controllo è esercitato anche sul bootloader, ad esempio GRUB per molte distribuzioni Linux.

In caso di vulnerabilità scoperte in un bootloader, come GRUB, risulta necessario indicare come “non affidabili” tutte le versioni compromesse. L’approccio classico consiste nell’indicare l’hash dei componenti software inaffidabili, inserendoli in una lista di revoca memorizzata nel firmware.

Il problema di fondo è che ogni distribuzione Linux può compilare una versione diversa di GRUB, con hash differenti. La gestione delle revoche diventa così estremamente complicata e inefficiente. Inoltre, lo spazio per memorizzare le liste di revoca nel firmware è limitato.

L’introduzione di SBAT

SBAT nasce nel 2012 proprio con l’obiettivo di risolvere il problema descritto. Invece di basarsi su una lista di revoche contenenti hash, SBAT utilizza un meccanismo incentrato sulle versioni dei bootloader e degli altri componenti caricati al boot.

Ogni componente critico della catena di avvio (come GRUB) dichiara una “security generation” ossia una versione numerica che rappresenta lo stato di sicurezza di un componente nella catena di avvio. Il numero è incrementato ogni volta che viene risolta una vulnerabilità nel componente corrispondente.

Durante l’avvio del dispositivo, il firmware controlla la “security generation” di ciascun componente: nel caso in cui la versione specificata fosse inferiore a quella richiesta dall’aggiornamento di sicurezza corrente, il componente è considerato non affidabile e l’avvio viene bloccato.

L’approccio SBAT permette di evitare la gestione di lunghe liste di hash revocati. Basta infatti aggiornare un singolo valore (“security generation“): indica che tutte le versioni precedenti sono da considerarsi automaticamente non sicure.

Il legame tra SBAT e Shim

Shim è un piccolo bootloader, del quale abbiamo spesso parlato, che funge da intermediario tra il firmware UEFI e il bootloader principale, come GRUB. Il fine è quello di consentire l’avvio di bootloader e kernel Linux non firmati direttamente da Microsoft, ma che comunque devono essere considerati affidabili all’interno del meccanismo di Secure Boot.

È il meccanismo che ha permesso a un numero incalcolabile di distribuzioni Linux e di tool di terze parti basati sul kernel del pinguino di avviarsi senza difficoltà anche sui sistemi protetti con Secure Boot.

Uno strumento come Shim è responsabile della gestione delle informazioni di SBAT. Verifica la “security generation” dei componenti successivi nella catena di avvio e se rileva che un componente ha una versione inferiore rispetto a quella richiesta, blocca l’avvio con la visualizzazione del messaggio di errore “Something has gone seriously wrong“.

Qual è la causa dei problemi introdotti da Microsoft con il dual boot tra Linux e Windows

Il problema che ha coinvolto tanti sistemi sui quali era configurato il dual boot tra Windows e Linux è emerso quando Microsoft ha rilasciato, a ferragosto 2024, un aggiornamento di Windows che aggiorna il comportamento di SBAT. L’azienda di Redmond ha indicato che tutte le versioni del bootloader GRUB con una “security generation” inferiore a una certa release, non possono più essere considerate affidabili.

L’aggiornamento introdotto da Microsoft è assolutamente sensato dal punto di vista della sicurezza: gli utenti usano versioni vulnerabili di GRUB che possono essere sfruttate per compromettere la catena di avvio sicuro di Windows.

Tuttavia, alcune distribuzioni Linux non avevano ancora distribuito versioni aggiornate di GRUB con una “security generation” più alta. Questo ha portato a una situazione in cui i sistemi con dual boot (cioè con installati sia Linux che Windows) non riuscivano ad avviare Linux, poiché il bootloader GRUB era considerato non affidabile e quindi bloccato.

Microsoft aveva intenzione di applicare l’aggiornamento SBAT solo ai sistemi con Windows in modalità standalone, lasciando i sistemi dual boot vulnerabili fino a quando le distribuzioni Linux non avessero aggiornato GRUB. Purtroppo, l’aggiornamento è stato invece distribuito e applicato anche ai sistemi dual boot, causando l’impossibilità di avviare Linux.

Di chi è la responsabilità dell’accaduto

Microsoft avrebbe dovuto testare meglio l’aggiornamento per evitare di bloccare i sistemi dual boot, mentre alcune distribuzioni Linux hanno indugiato troppo nel fornire gli aggiornamenti di GRUB più recenti.

Gli utenti finali, purtroppo, hanno pagato il prezzo dell’errore, ritrovandosi con sistemi che non si avviano più come previsto.

Quanto accaduto sottolinea l’importanza di un coordinamento più stretto tra i fornitori di sistemi operativi e i manutentori delle distribuzioni, per garantire che l’applicazione di soluzioni di sicurezza non causino disagi agli utenti.

Credit immagine in apertura: Copilot Designer