PoC e rapporto di vulnerabilità per CVE-2025-47827.
Prova di concetto e rapporto di vulnerabilità per CVE-2025-47827.
In IGEL OS precedenti alla v11, Secure Boot può essere aggirato perché il modulo igel-flash-driver verifica impropriamente una firma crittografica. In definitiva, un filesystem root appositamente creato può essere montato da un'immagine SquashFS non verificata.
La verifica impropria della firma crittografica nel modulo del kernel Linux igel-flash-driver in IGEL OS 10 consente a un attore malintenzionato di aggirare Secure Boot, avviando lo shim firmato da Microsoft 3rd Party UEFI CA, che carica quindi GRUB e il kernel vulnerabile, entrambi firmati da IGEL Secure Boot Signing CA. Una volta caricato il kernel vulnerabile e l'initramfs incorporato, un filesystem root malintenzionato può essere montato dall'immagine SquashFS non verificata sul disco.
Poiché la syscall kexec_load è disponibile nel kernel vulnerabile, il kernel attualmente avviato può essere sostituito con uno completamente non fidato, consentendo praticamente l'avvio di qualsiasi sistema operativo, dopo una completa catena di fiducia.
Nelle versioni successive di IGEL OS, il modulo verifica correttamente una firma dell'immagine SquashFS del filesystem root. Tuttavia, sia il kernel vulnerabile che le versioni corrette sono firmati con lo stesso certificato, consentendo allo stesso shim di avviare sia le versioni vulnerabili che quelle corrette.
La stringa del vettore iniziale per CVE-2025-47827 era AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, con un punteggio CVSS di 8.4 (alto).
Il 14 ottobre 2025, questo è stato cambiato in AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, abbassando il punteggio a 4.6 (medio).
Inoltre, la debolezza originale è stata definita come CWE-347: Improper Verification of Cryptographic Signature, ma MSRC l'ha assegnata come CWE-324: Use of a Key Past its Expiration Date.
Sia IGEL che Microsoft sono stati contattati e informati di questa vulnerabilità, rispettivamente il 6 dicembre 2024 e il 31 marzo 2025, prima che i dettagli venissero resi pubblici il 29 maggio 2025.
Poiché IGEL OS 10 non è supportato e la vulnerabilità non esiste direttamente all'interno dello shim, nessuna delle due parti ha suggerito una risoluzione. Microsoft ha risposto con quanto segue:
Dopo un'indagine, abbiamo stabilito che questa segnalazione non soddisfa la definizione di vulnerabilità di sicurezza per la correzione poiché IGEL OS v10 non è più supportato e il problema è nel modulo del kernel e non nello shim. Solo lo shim è firmato dal certificato MSFT.
IGEL ha pubblicato un avviso di sicurezza per CVE-2025-47827 il 2 giugno 2025.
Il 13 giugno 2025, ho segnalato nuovamente questo a Microsoft e ho ricevuto la seguente risposta:
Sebbene la tua segnalazione contenesse alcune buone informazioni, non soddisfa il requisito di Microsoft per una vulnerabilità di sicurezza da correggere. Il problema segnalato è nel modulo del kernel e non nello shim, e solo lo shim è firmato dal certificato MSFT. kexec già permette di aggirare secure boot per progettazione (Rif: kexec Command Line in Linux - Linux Expert Better 2025).
Questo soddisferebbe i criteri di correzione di MSRC se il problema fosse in un driver/componente di avvio. Questa è una vulnerabilità nel driver del kernel della distribuzione Linux. Questo avviene dopo UEFI "ExitBootServices", il che significa che non è un bypass di Secure Boot. L'utente ha solo esecuzione di codice a livello di sistema operativo, non di avvio.
Dalla pubblicazione di vari articoli di notizie riguardanti questa vulnerabilità, i manutentori dello shim hanno collaborato con Microsoft e IGEL per discutere una risoluzione.
Dopo che è stata raggiunta una risoluzione, ho creato un altro caso su MSRC il 20 ottobre 2025, chiedendo il motivo del ritardo nella revoca di questi shim, modifiche alla stringa del vettore CVSS e CWE e perché la loro guida agli aggiornamenti affermava che la vulnerabilità non era stata divulgata pubblicamente. Ho ricevuto la seguente risposta:
La vulnerabilità IGEL che è stata corretta non è un bypass di Secure Boot. È un bypass dell'integrità del Kernel specifico di Linux e non influisce su Windows. Gli shim IGEL sono vecchi e non supportano la nuova revoca basata su SBAT. Pertanto, Microsoft ha emesso le revoche per proteggere da potenziali sfruttamenti di altre vulnerabilità che sono state protette da SBAT.
Jeffrey Sutherland, Principal Lead Program Manager, ha risposto sulla PR spiegando che, a causa della mancanza di SBAT, gli shim hanno dovuto essere revocati tramite DBX, e IGEL ha richiesto tempo aggiuntivo per evitare conseguenze indesiderate. Si sono anche scusati per non aver mantenuto la comunicazione tra il ricercatore e le parti coinvolte, come richiesto dalla Divulgazione Coordinata delle Vulnerabilità.
Un exploit di bypass di Secure Boot potrebbe portare allo sviluppo di un bootkit/rootkit a livello di kernel non rilevato, a sua volta portando a molteplici implicazioni, come:
Senza revoca o intervento manuale, Secure Boot è stato reso inutile su tutte le macchine che si fidano del Microsoft 3rd Party UEFI CA, che è l'impostazione predefinita per la maggior parte dei dispositivi al momento della scrittura.
Se utilizzata per kexec, questa vulnerabilità può essere sfruttata per modificare silenziosamente e maliziosamente un sistema legittimo, senza influire su Secure Boot.
