Secure Boot aggirabile per 13 anni tramite shim firmati non revocati

ESET ha individuato 11 immagini “shim” vulnerabili, firmate e mai revocate, con almeno un campione datato 2013. Con queste immagini si elude Secure Boot e si avvia codice malevolo su dispositivi Windows e Linux¹.

Secure Boot impone che ogni fase dell’avvio provenga da componenti firmati e autorizzati. Il controllo vive nell’UEFI e blocca binari non ammessi. Microsoft ne ha spinto l’uso sui PC Windows; il meccanismo si è poi esteso anche a Linux¹.

Gli shim servono a integrare Secure Boot nei sistemi Linux e in strumenti di utilità. La firma di queste immagini passa dal processo supervisionato da Microsoft. Alcune versioni sono risultate difettose. Sono rimaste scaricabili e valide per la firma, senza una revoca che ne impedisse l’uso¹.

Uno shim vulnerabile basta a scardinare la catena. Si installa lo shim, il firmware UEFI lo accetta perché firmato, la verifica a cascata non regge più. A quel punto l’attaccante carica componenti non autorizzati, incluso firmware malevolo. ESET segnala che bastano competenze modeste per sfruttare la falla¹.

Stesso esito su macchine con Windows o Linux. Gli shim firmati attraversano ambienti diversi perché Secure Boot valuta la firma, non la piattaforma. Se l’infrastruttura accetta immagini datate ma valide, la garanzia di avvio sicuro si indebolisce¹.

Nodo centrale: la revoca mancante. Microsoft gestisce il flusso di firma per gli shim. Quando sono emerse vulnerabilità, quelle immagini non sono state rimosse dall’elenco dei componenti ammessi. Ne è derivata una finestra di attacco durata anni: per un arco che parte almeno dal 2013, shim difettosi ma firmati hanno consentito il bypass di Secure Boot. La ricostruzione di ESET arriva alla verifica attuale delle 11 immagini vulnerabili¹.

La lezione è operativa. La firma autentica l’origine, ma la sicurezza resta monca senza una gestione rigorosa delle revoche. Senza manutenzione continua, anche controlli radicati nell’UEFI diventano aggirabili con software obsoleto ma ancora accettato. Il caso ESET mostra come l’affidabilità di Secure Boot dipenda tanto dall’inclusione di ciò che è lecito quanto dall’esclusione tempestiva di ciò che non lo è¹.