La minaccia degli “shim UEFI”: ESET scopre 11 vecchi software Microsoft che annullano le difese Secure Boot

🛡️ Executive Summary

• Undici vecchi shim UEFI firmati da Microsoft possono avviare codice non attendibile su sistemi che considerano valida la CA UEFI di terze parti.
• Gli attaccanti possono portare autonomamente shim e bootloader vulnerabili, aggirare Secure Boot e installare bootkit come Bootkitty, HybridPetya o BlackLotus.
• Microsoft ha revocato i binari con l’aggiornamento dbx del 9 giugno 2026; Windows e Linux devono ricevere le revoche più recenti.

ESET Research ha scoperto 11 vecchi shim UEFI firmati da Microsoft che possono essere utilizzati per aggirare UEFI Secure Boot ed eseguire codice non attendibile durante l’avvio del computer. I binari vulnerabili, appartenenti alle versioni 0.9 e precedenti, provengono da distribuzioni Linux, strumenti diagnostici e altre utility UEFI ormai dimenticate. Il rischio non riguarda soltanto i dispositivi sui quali questi software sono installati: un attaccante può portare una propria copia dello shim vulnerabile su qualsiasi macchina che continui a considerare attendibile il certificato Microsoft Corporation UEFI CA 2011. Microsoft ha revocato gli undici binari con l’aggiornamento dbx del 9 giugno 2026.

Vecchi shim firmati restano attendibili su milioni di sistemi UEFI

Lo shim è un piccolo bootloader utilizzato soprattutto dalle distribuzioni Linux per inserirsi nella catena di fiducia di Secure Boot. Il firmware verifica la firma Microsoft dello shim, che a sua volta controlla il bootloader successivo, generalmente GRUB 2, usando il certificato incorporato dal produttore della distribuzione. Questo modello evita che Microsoft debba firmare ogni versione di GRUB e del kernel, ma attribuisce allo shim un ruolo decisivo: quando un vecchio binario rimane firmato e non viene inserito nella denylist dbx, continua a essere considerato affidabile anche se contiene vulnerabilità note o carica componenti ormai insicuri. L’analisi pubblicata da ESET mostra che gli undici shim identificati possono essere usati sulla maggior parte delle macchine UEFI che accettano il certificato Microsoft per il software di terze parti, indipendentemente dal sistema operativo effettivamente installato.

Un aggressore con privilegi sufficienti per modificare la EFI System Partition può quindi copiare uno shim vulnerabile e un secondo-stage bootloader ancora considerato valido, ottenendo una catena formalmente firmata ma tecnicamente compromessa. Il problema conferma quanto già osservato nelle vulnerabilità UEFI dei sistemi Gigabyte: la sicurezza del boot non dipende soltanto dal firmware presente sul dispositivo, ma dall’intero archivio storico dei componenti firmati che il firmware è ancora disposto ad avviare.

GRUB 2 e i bootloader di secondo stadio ampliano la superficie di attacco

Le vulnerabilità sono state catalogate come CVE-2026-8863 e CVE-2026-10797, ma il rischio non può essere ricondotto a due soli difetti. Ogni shim incorpora certificati che autorizzano bootloader, MokManager, utility di fallback e altri componenti prodotti nel corso degli anni. ESET ha individuato applicazioni fidate compilate tra il 2013 e il 2025, molte delle quali utilizzano versioni datate di GRUB 2 affette da vulnerabilità pubblicamente note. Un esempio riguarda uno shim di Oracle Linux che può caricare un GRUB vulnerabile a CVE-2015-5281: l’attaccante non deve costruire una complessa catena ROP o sfruttare una memory corruption, perché può utilizzare il comando multiboot2 per eseguire un kernel non firmato durante l’avvio.

In questo scenario Secure Boot resta formalmente attivo, ma la sua garanzia viene annullata da un componente vecchio che Microsoft aveva firmato e che la macchina non aveva ancora revocato. È lo stesso principio che ha reso pericolosi Bootkitty e le vulnerabilità LogoFAIL nei sistemi Linux UEFI: una volta ottenuta l’esecuzione prima del sistema operativo, il malware può alterare kernel, moduli e meccanismi di sicurezza prima che EDR e antivirus abbiano iniziato a funzionare. Gli shim vulnerabili possono quindi favorire l’installazione di bootkit come Bootkitty, HybridPetya o BlackLotus, garantendo una persistenza particolarmente difficile da rilevare e rimuovere.

CVE-2026-10797 aggira le revoche attraverso una firma manipolata

Una delle debolezze più rilevanti, oggi identificata come CVE-2026-10797, era stata corretta nel progetto shim circa dieci anni fa, ma non aveva mai ricevuto un CVE e continuava a esistere nei binari più vecchi. Il problema nasce dal fatto che un eseguibile PE firmato tramite Authenticode registra la lunghezza della firma in due punti differenti: nel data directory dell’header PE e nella struttura WIN_CERTIFICATE. Gli shim vulnerabili utilizzano un valore per verificare la revoca e l’altro per validare la firma.

Un attaccante può quindi alterare la struttura WIN_CERTIFICATE affinché il controllo contro dbx o MokListX analizzi dati non corretti, mentre la verifica crittografica continua a considerare valida la firma effettiva del bootloader. Il bypass riguarda le revoche basate sui certificati incorporati nello shim e permette di caricare componenti che l’amministratore riteneva esclusi. Gli shim precedenti alla versione 0.9 ignorano inoltre correttamente la denylist MOK, mentre quelli anteriori alla versione 15.3 non supportano Secure Boot Advanced Targeting, il sistema che revoca intere generazioni di shim e GRUB attraverso numeri di versione. Un attaccante può pertanto sostituire uno shim moderno con uno più vecchio, firmato da Microsoft ma privo dei controlli introdotti successivamente. La dinamica ricorda il precedente di BlackLotus, il bootkit capace di bypassare Secure Boot sui sistemi aggiornati, perché sfrutta la fiducia residua concessa a bootloader vulnerabili invece di violare direttamente la crittografia.

La scadenza del certificato Microsoft non revoca automaticamente i binari

Il certificato Microsoft Corporation UEFI CA 2011 è scaduto il 27 giugno 2026, ma la scadenza non impedisce ai firmware di continuare a eseguire i binari firmati. Nel modello Secure Boot, un’applicazione resta attendibile finché il certificato o il suo hash sono presenti nella database consentita db e non risultano inseriti nella denylist dbx. Di conseguenza, la fine della validità temporale della CA non ritira automaticamente shim e bootloader firmati in passato. Questa caratteristica spiega perché Microsoft abbia dovuto revocare individualmente gli hash degli undici binari attraverso il Patch Tuesday del 9 giugno 2026. Il problema più ampio riguarda però la visibilità: dal 2017 le richieste di firma degli shim vengono pubblicate nel repository shim-review e sottoposte a un processo più trasparente, mentre non esiste un catalogo completo di tutti i binari approvati negli anni precedenti. Nessuno può quindi stabilire con certezza quanti vecchi shim firmati siano ancora disponibili e sfruttabili. Le ricerche sulle vulnerabilità UEFI e sugli aggiornamenti di sicurezza dei firmware mostrano che il problema delle revoche non può essere affrontato soltanto quando emerge un nuovo exploit: ogni componente firmato diventa parte permanente della superficie di attacco finché non viene inventariato e ritirato in modo esplicito.

Microsoft revoca gli shim ma gli amministratori devono verificare la dbx

Microsoft ha inserito gli hash degli undici shim nella UEFI Secure Boot Forbidden Signature Database distribuita con gli aggiornamenti di giugno. I sistemi Windows correttamente aggiornati dovrebbero ricevere automaticamente la nuova dbx, mentre su Linux le revoche possono essere distribuite attraverso i pacchetti del produttore e il Linux Vendor Firmware Service. Gli amministratori non devono però limitarsi a verificare che Secure Boot risulti abilitato nel firmware: devono controllare che la denylist contenga effettivamente le nuove revoche, applicare gli aggiornamenti UEFI e firmware disponibili e monitorare modifiche alla EFI System Partition. ESET mette a disposizione comandi PowerShell per confrontare gli hash vulnerabili con il contenuto locale della dbx, mentre sui sistemi Linux può essere utilizzato lo script uefi-dbx-audit. Nei contesti aziendali è opportuno controllare anche eventi di avvio anomali, cambiamenti nei file shim e GRUB, nuove chiavi MOK e configurazioni che riabilitano la CA Microsoft per il software di terze parti. I PC Windows 11 Secured-core dovrebbero disabilitare questa fiducia per impostazione predefinita, ma molte altre macchine continuano a mantenerla attiva per garantire compatibilità con Linux e utility UEFI. La vicenda conferma che Secure Boot non è una protezione statica: la sua efficacia dipende dalla manutenzione continua delle revoche e dalla capacità di eliminare dalla catena di fiducia ogni binario firmato che non può più essere considerato sicuro.