{"id":119554,"date":"2024-08-21T09:43:00","date_gmt":"2024-08-21T07:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot"},"modified":"2024-08-21T09:43:00","modified_gmt":"2024-08-21T07:43:00","slug":"oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","title":{"rendered":"Un errore nell'aggiornamento di Windows ha bloccato il caricamento di Linux durante l'utilizzo di UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nell'aggiornamento rilasciato marted\u00ec da Microsoft \u00e8 emerso un problema che impedisce il caricamento dei sistemi Linux installati sullo stesso computer in parallelo a Windows. La causa di questo problema \u00e8 una correzione mirata a risolvere una vecchia vulnerabilit\u00e0 (CVE-2022-2601) nel bootloader GRUB, corretta nel 2022. Microsoft non ha ancora rilasciato dichiarazioni riguardo al problema emerso e non l'ha commentato. <\/p>\n
La nota relativa alla modifica indicava che la correzione, che garantisce l'implementazione della nuova politica SBAT (UEFI Secure Boot Advanced Targeting), sar\u00e0 applicata ai sistemi che utilizzano esclusivamente Windows e non influenzer\u00e0 le configurazioni con avvio duale (la modifica bloccava la possibilit\u00e0 di utilizzare immagini di avvio con il vecchio GRUB per aggirare il Secure Boot sui sistemi in cui \u00e8 installato solo Windows). \u00c8 stato inoltre indicato che la modifica potrebbe causare problemi con il caricamento delle immagini ISO di vecchi sistemi, forniti con una versione vulnerabile di GRUB. In effetti, i problemi si sono manifestati anche per gli utenti di sistemi con avvio duale che utilizzano nuove distribuzioni Linux come Ubuntu 24.04 e Debian 12.6, in cui la vulnerabilit\u00e0 in GRUB \u00e8 stata corretta da tempo. <\/p>\n
Il problema si manifesta con l'arresto del processo di avvio, mostrando il messaggio \u00abVerifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation\u00bb. Come modo per ripristinare il funzionamento, si raccomanda di rimuovere i dati SBAT installati nel UEFI, disattivando Secure Boot nel firmware, scaricando una nuova distribuzione Linux compatibile con UEFI Secure Boot, come Ubuntu, ed eseguendo il comando in console \u00abmokutil --set-sbat-policy delete\u00bb, dopo di che riavviare la distribuzione Linux per impostare correttamente la politica SBAT. A questo punto, \u00e8 possibile ripristinare la modalit\u00e0 Secure Boot nel firmware. <\/p>\n
Il meccanismo SBAT \u00e8 stato sviluppato da Red Hat in collaborazione con Microsoft per bloccare le vulnerabilit\u00e0 nel caricatore GRUB e nello strato shim senza revocare la firma digitale. SBAT implica l'aggiunta di metadati esecutivi ai file dei componenti UEFI, i quali includono informazioni su produttore, prodotto, componente e versione. I metadati specificati sono firmati digitalmente e possono essere inclusi separatamente nelle liste di componenti autorizzati o vietati per il Secure Boot UEFI. SBAT consente di bloccare l'uso della firma digitale per numeri di versione specifici dei componenti senza la necessit\u00e0 di revocare le chiavi per il Secure Boot. <\/p>\n
Il blocco delle vulnerabilit\u00e0 tramite SBAT non richiede l'uso dell'elenco dei certificati UEFI revocati (dbx), ma avviene a livello di sostituzione della chiave interna per la generazione di firme e l'aggiornamento di GRUB2, shim e altri artefatti di avvio forniti dai rispettivi distributori. Prima dell'implementazione di SBAT, l'aggiornamento dell'elenco dei certificati revocati (dbx, UEFI Revocation List) era una condizione necessaria per il blocco completo della vulnerabilit\u00e0, dato che un attaccante, indipendentemente dal sistema operativo utilizzato, poteva compromettere UEFI Secure Boot utilizzando un supporto di avvio con una vecchia versione vulnerabile di GRUB2, firmata digitalmente. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"