{"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\/news\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","title":{"rendered":"Un errore nell'aggiornamento a Windows ha bloccato l'avvio di Linux quando si utilizza UEFI Secure Boot.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nell'aggiornamento rilasciato marted\u00ec da Microsoft per il sistema operativo Windows \u00e8 emerso un problema che impedisce l'avvio dei sistemi Linux installati sullo stesso computer insieme a Windows. La causa del problema \u00e8 una correzione volta a risolvere una vecchia vulnerabilit\u00e0 (CVE-2022-2601) nel bootloader GRUB, risolta nel 2022. Microsoft non ha ancora pubblicato dichiarazioni riguardo l'errore emerso e non l'ha commentato. <\/p>\n
Nel commento sul cambiamento si specificava che la correzione, che implementa una nuova politica SBAT (UEFI Secure Boot Advanced Targeting), sar\u00e0 applicata ai sistemi che utilizzano solo Windows e non influenzer\u00e0 le configurazioni a doppio avvio (la modifica bloccava la possibilit\u00e0 di utilizzare immagini di avvio con il vecchio GRUB per bypassare Secure Boot sui sistemi con Windows installato). Si segnalava inoltre che il cambiamento potrebbe causare problemi con il caricamento di immagini iso di vecchi sistemi forniti con una versione vulnerabile di GRUB. In realt\u00e0, i problemi si sono manifestati anche per gli utenti di sistemi a doppio avvio che utilizzano nuove distribuzioni Linux, come Ubuntu 24.04 e Debian 12.6, in cui la vulnerabilit\u00e0 in GRUB \u00e8 stata a lungo risolta. <\/p>\n
Il problema si manifesta con l'arresto del processo di avvio e il messaggio \"Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation\". Per ripristinare il funzionamento, si consiglia di eliminare i dati SBAT installati in UEFI, disabilitando Secure Boot nel firmware, caricando una nuova distribuzione Linux che supporti UEFI Secure Boot, come Ubuntu, ed eseguendo nel terminale il comando \"mokutil --set-sbat-policy delete\", quindi riavviando la distribuzione Linux per impostare correttamente la politica SBAT. Dopo ci\u00f2, \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 bootloader GRUB e nello shim senza revocare la firma digitale. SBAT implica l'aggiunta di metadati ai file eseguibili dei componenti UEFI, che includono informazioni su produttore, prodotto, componente e versione. I metadati indicati sono firmati digitalmente e possono essere inclusi separatamente nell'elenco dei componenti consentiti o vietati per l'UEFI Secure Boot. SBAT consente di bloccare l'uso della firma digitale per singoli numeri di versione 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 di certificati revocati UEFI (dbx) ed avviene a livello di sostituzione della chiave interna per la generazione delle firme e l'aggiornamento di GRUB2, shim e altri artefatti di avvio forniti con le distribuzioni. Prima dell'implementazione di SBAT, l'aggiornamento dell'elenco di certificati revocati (dbx, UEFI Revocation List) era una condizione necessaria per un blocco completo delle vulnerabilit\u00e0, poich\u00e9 un attaccante, indipendentemente dal sistema operativo utilizzato, poteva compromettere l'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":"