Gli sviluppatori di Fedora Linux hanno chiarito la situazione riguardante la scadenza, alla fine di giugno, del certificato Microsoft utilizzato per firmare digitalmente il layer Shim, impiegato per il caricamento verificato delle distribuzioni Linux in modalità UEFI Secure Boot. Il passaggio a un nuovo certificato dovrà avvenire senza che gli utenti se ne accorgano, poiché di fatto la scadenza della vita del certificato comporterà soltanto l'impossibilità di utilizzarlo per la creazione di nuove firme. Durante il caricamento in UEFI Secure Boot, la scadenza del certificato non viene verificata ed è rilevante solo per il ritiro dei certificati compromessi.
I sistemi esistenti senza l'aggiornamento shim continueranno a caricarsi finché la chiave pubblica del certificato non verrà rimossa dal firmware o non sarà inserita nella lista dei certificati revocati UEFI (DBX). Il layer di avvio shim è firmato solo dalla chiave Microsoft, che contiene la chiave pubblica della distribuzione utilizzata per firmare i componenti caricati, come il bootloader GRUB2, il kernel Linux, i moduli del kernel e i processi impiegati durante il caricamento, come fwupd. Questo approccio consente a Microsoft di certificare solo le modifiche al layer shim e di garantire autonomamente la verifica del processo di caricamento della distribuzione.
Il certificato Microsoft per la firma di firmware di terze parti per UEFI Secure Boot è in vigore dal 2011. Nel 2023, è stato generato un nuovo certificato, che sarà utilizzato per la formazione delle firme a partire da ottobre 2025. Nel repository Fedora Rawhide, su cui si basa il rilascio di Fedora 45, è già stato aggiunto un shim aggiornato, firmato da più chiavi per garantire la massima compatibilità con l'hardware (può essere utilizzato sia su firmware più vecchi senza la chiave pubblica del nuovo certificato, sia su firmware senza la chiave pubblica del vecchio certificato).
Nonostante la scadenza del certificato Microsoft non dovrebbe influire sulla funzionalità di avvio, gli sviluppatori di Fedora raccomandano agli utenti di aggiornare il database con le chiavi per Secure Boot non appena sono disponibili nuove versioni del firmware per la loro attrezzatura. Per verificare se il sistema è stato avviato in modalità UEFI Secure Boot, si può usare il comando «mokutil —sb-state», mentre per visualizzare l'elenco delle chiavi aperte incluse nel firmware, si può utilizzare «mokutil —db —short». Per visualizzare le chiavi con cui è firmato lo shim, si può eseguire il comando «sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi», previa installazione del pacchetto pesign. Per controllare la disponibilità di aggiornamenti del firmware e installarli, si può eseguire il comando «sudo fwupdmgr update».
La prossima versione dello shim sarà firmata esclusivamente con un nuovo certificato Microsoft, e l'aggiornamento del firmware è necessario per preparare i propri sistemi a questo cambiamento. L'aggiornamento dello shim sarà rilasciato nel caso vengano scoperte vulnerabilità o gravi errori, che possono manifestarsi sia a un mese che a un anno di distanza. Durante il periodo di esistenza dello shim nel progetto sono state trovate vulnerabilità critiche, e l'ultimo rapporto su problemi di sicurezza riguardanti lo shim è stato pubblicato solo pochi giorni fa.
Nel rapporto sono state segnalate due vulnerabilità recentemente scoperte: CVE-2026-8863 e
CVE-2026-10797, che consentono l'esecuzione di codice personalizzato all'inizio del processo di avvio, prima di trasferire il controllo al sistema operativo, di aggirare la protezione UEFI Secure Boot e di consentire l'avvio di componenti del kernel privi di firma digitale. I problemi interessano le versioni di shim fino alla versione 0.9 inclusa, rilasciate prima del 2016. I sistemi molto datati sono vulnerabili, come
RedHat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, ROSA Linux R10/R9 e openSUSE con shim 0.9. Gli shim fino alla versione 0.9 inclusa sono stati aggiunti al database delle firme digitali revocate DBX (UEFI Forbidden Signature Database) e, in caso di aggiornamento del DBX, non saranno utilizzabili per l'avvio in modalità UEFI Secure Boot.
Fonte: opennet.ru
