{"id":99320,"date":"2021-03-03T16:22:39","date_gmt":"2021-03-03T14:22:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2021-03-03T16:22:39","modified_gmt":"2021-03-03T14:22:39","slug":"trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Vulnerabilit\u00e0 difficili da risolvere in GRUB2, che consentono di bypassare UEFI Secure Boot.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Sono state divulgate informazioni su 8 vulnerabilit\u00e0 nel bootloader GRUB2, che consentono di eludere il meccanismo UEFI Secure Boot e avviare codice non verificato, ad esempio per inserire malware che opera a livello di bootloader o kernel. <\/p>\n
Ricordiamo che nella maggior parte delle distribuzioni Linux, per l'avvio verificato in modalit\u00e0 UEFI Secure Boot viene utilizzato un piccolo strato shim, certificato con una firma digitale di Microsoft. Questo strato verifica GRUB2 con un proprio certificato, il che consente agli sviluppatori delle distribuzioni di non certificare ogni aggiornamento del kernel e di GRUB presso Microsoft. Le vulnerabilit\u00e0 in GRUB2 consentono di eseguire il proprio codice in una fase dopo la verifica riuscita di shim, ma prima del caricamento del sistema operativo, interrompendo la catena di fiducia in modalit\u00e0 Secure Boot attiva e ottenendo il pieno controllo del processo di avvio successivo, inclusa l'avviabilit\u00e0 di un altro sistema operativo, la modifica dei componenti del sistema operativo e l'elusione della protezione Lockdown. <\/p>\n
Come nel caso della vulnerabilit\u00e0 BootHole dello scorso anno, per bloccare questo problema non \u00e8 sufficiente aggiornare il bootloader, poich\u00e9 l'attaccante, indipendentemente dal sistema operativo utilizzato, pu\u00f2 compromettere UEFI Secure Boot utilizzando un supporto di avvio con una vecchia versione vulnerabile di GRUB2, certificata con una firma digitale. Il problema viene risolto solo aggiornando l'elenco dei certificati revocati (dbx, UEFI Revocation List), ma in questo caso si perder\u00e0 la possibilit\u00e0 di utilizzare vecchi supporti di installazione con Linux. <\/p>\n
Su sistemi con firmware in cui \u00e8 stato aggiornato l'elenco dei certificati revocati, in modalit\u00e0 UEFI Secure Boot sar\u00e0 possibile avviare solo versioni aggiornate delle distribuzioni Linux. Le distribuzioni dovranno aggiornare gli installer, i bootloader, i pacchetti del kernel, le firmware fwupd e lo strato shim, generando nuove firme digitali per essi. Gli utenti dovranno aggiornare le immagini di installazione e altri supporti di avvio, oltre a caricare l'elenco dei certificati revocati (dbx) nel firmware UEFI. Fino all'aggiornamento di dbx in UEFI, il sistema rimane vulnerabile indipendentemente dagli aggiornamenti installati nel sistema operativo. Lo stato della risoluzione delle vulnerabilit\u00e0 pu\u00f2 essere valutato su queste pagine: Ubuntu, SUSE, RHEL, Debian. <\/p>\n
Per risolvere i problemi che sorgono con la distribuzione dei certificati revocati, in futuro si prevede di utilizzare il meccanismo SBAT (UEFI Secure Boot Advanced Targeting), il cui supporto \u00e8 implementato per GRUB2, shim e fwupd, e a partire dai prossimi aggiornamenti verr\u00e0 utilizzato al posto della funzionalit\u00e0 fornita dal pacchetto dbxtool. SBAT \u00e8 stato sviluppato in collaborazione con Microsoft e prevede l'aggiunta di nuovi metadati nei file eseguibili dei componenti UEFI, che includono informazioni sul produttore, sul prodotto, sul componente e sulla versione. I metadati indicati vengono firmati digitalmente e possono essere inclusi anche nelle liste di componenti autorizzati o vietati per UEFI Secure Boot. Pertanto, SBAT consentir\u00e0 di manipolare i numeri di versione dei componenti in caso di revoca, senza la necessit\u00e0 di rigenerare le chiavi per Secure Boot e senza creare nuove firme per il kernel, shim, grub2 e fwupd. <\/p>\n