Nel layer Shim, utilizzato nella maggior parte delle distribuzioni Linux per l'avvio verificato in modalit\u00e0 Secure Boot UEFI, \u00e8 stata identificata una vulnerabilit\u00e0 (CVE-2023-40547) che pu\u00f2 portare all'esecuzione remota di codice e all'elusione del meccanismo di avvio verificato UEFI Secure Boot. Un attaccante che controlla il server HTTP a cui si rivolge Shim pu\u00f2 restituire una risposta appositamente formattata che provoca una scrittura controllata oltre il limite del buffer per organizzare l'esecuzione del codice nelle fasi iniziali di avvio. <\/p>\n
La vulnerabilit\u00e0 \u00e8 causata da un errore nel codice di caricamento dei file tramite HTTP, che si manifesta durante l'elaborazione delle risposte non corrette restituite dal server HTTP a cui si rivolge shim. Il modo HTTPBoot in Shim \u00e8 supportato dal 2016 e consente di organizzare il caricamento in rete, utilizzando il protocollo HTTP per estrarre il file con il caricatore, richiamato nella fase successiva. Shim, durante il caricamento dei file tramite HTTP, riserva un buffer per i dati ricevuti, considerando non la dimensione effettiva dei dati, ma la dimensione indicata nell'intestazione HTTP \"Content-Length\". Pertanto, restituendo un valore inferiore nell'intestazione Content-Length, \u00e8 possibile ottenere la registrazione della coda della richiesta in memoria al di fuori del buffer. <\/p>\n
Shim \u00e8 certificato con firma digitale da Microsoft e verifica GRUB2 con il proprio certificato, consentendo agli sviluppatori di distribuzioni di non dover certificare ogni aggiornamento del kernel e di GRUB presso Microsoft. La vulnerabilit\u00e0 in Shim consente di infiltrarsi nella catena di fiducia in modalit\u00e0 Secure Boot attiva, ottenendo il pieno controllo sul processo di avvio successivo, ad esempio per caricare un altro sistema operativo, modificare componenti del sistema operativo e eludere la protezione Lockdown. <\/p>\n
La vulnerabilit\u00e0 \u00e8 stata corretta nella versione Shim 15.8, ma per bloccare completamente l'attacco tramite Shim \u00e8 necessaria la certificazione della nuova versione da parte di Microsoft e la sua implementazione nelle distribuzioni. Lo stato di correzione della vulnerabilit\u00e0 nelle distribuzioni pu\u00f2 essere valutato su queste pagine: Debian, Ubuntu, SUSE, RHEL, Fedora. Il problema \u00e8 che senza la revoca della firma della vecchia versione, la correzione \u00e8 inutile, poich\u00e9 un attaccante pu\u00f2 compromettere il Secure Boot UEFI usando un supporto di avvio con una versione vulnerabile di Shim. Tuttavia, la revoca della firma comporterebbe l'impossibilit\u00e0 dell'avvio verificato delle distribuzioni che continuano a utilizzare la vecchia versione di Shim. <\/p>\n
Per bloccare la vulnerabilit\u00e0 senza revocare la firma digitale, i distributori possono utilizzare il meccanismo SBAT (UEFI Secure Boot Advanced Targeting), il cui supporto \u00e8 stato implementato per GRUB2, shim e fwupd nella maggior parte dei distribuiti Linux. SBAT \u00e8 stato sviluppato congiuntamente a Microsoft e implica l'aggiunta di metadati ai file eseguibili dei componenti UEFI, che includono informazioni sul produttore, prodotto, componente e versione. I metadati indicati sono firmati digitalmente e possono essere inclusi separatamente nelle liste di componenti consentiti o vietati per UEFI Secure Boot. <\/p>\n
SBAT consente di bloccare l'uso della firma digitale per singoli numeri di versione dei componenti senza necessit\u00e0 di revocare le chiavi per Secure Boot. Il blocco delle vulnerabilit\u00e0 tramite SBAT non richiede l'uso dell'elenco dei certificati revocati UEFI (dbx), ma viene effettuato a livello di sostituzione della chiave interna per la generazione delle firme e l'aggiornamento di GRUB2, shim e altri artefatti di avvio forniti dalle distribuzioni. <\/p>\n
Oltre alla vulnerabilit\u00e0 considerata, in Shim 15.8 sono stati corretti anche diversi problemi meno gravi, sfruttabili localmente: <\/p>\n