{"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\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Vulnerabilit\u00e0 critiche in GRUB2 che consentono di eludere UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Svelate informazioni su 8 vulnerabilit\u00e0 nel bootloader GRUB2 che consentono di aggirare il meccanismo UEFI Secure Boot e di eseguire codice non verificato, ad esempio, consentendo l'installazione di malware a livello di bootloader o kernel. <\/p>\n
Ricordiamo che nei principali distribuzioni Linux, per il boot verificato in modalit\u00e0 UEFI Secure Boot, viene utilizzato un piccolo strato shim, firmato digitalmente da Microsoft. Questo strato verifica GRUB2 con il proprio certificato, consentendo agli sviluppatori delle distribuzioni di non dover firmare ogni aggiornamento del kernel e di GRUB con Microsoft. Le vulnerabilit\u00e0 in GRUB2 possono portare all'esecuzione di codice proprio in un momento successivo alla verifica riuscita dello shim, ma prima del caricamento del sistema operativo, infiltrandosi nella catena di fiducia in modalit\u00e0 Secure Boot attiva e ottenendo il controllo completo sul processo di avvio, inclusi il caricamento di un altro sistema operativo, la modifica dei componenti del sistema operativo e l'aggiramento della protezione Lockdown. <\/p>\n
Come per la vulnerabilit\u00e0 BootHole dell'anno scorso, aggiornare semplicemente il bootloader non \u00e8 sufficiente per risolvere il problema, poich\u00e9 un attaccante, indipendentemente dal sistema operativo in uso, pu\u00f2 compromettere UEFI Secure Boot utilizzando un supporto di avvio con una versione vulnerabile di GRUB2, firmata digitalmente. Il problema si risolve 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
Nei sistemi con firmware in cui \u00e8 stato aggiornato l'elenco dei certificati revocati, in modalit\u00e0 UEFI Secure Boot sar\u00e0 possibile avviare solo le versioni aggiornate delle distribuzioni Linux. Le distribuzioni dovranno aggiornare gli installer, i bootloader, i pacchetti del kernel, i firmware fwupd e il layer shim, generando nuove firme digitali per questi. Gli utenti dovranno aggiornare le immagini di installazione e altri supporti di avvio, nonch\u00e9 caricare l'elenco dei certificati revocati (dbx) nel firmware UEFI. Fino all'aggiornamento del dbx nell'UEFI, il sistema rimane vulnerabile indipendentemente dall'installazione degli aggiornamenti nel SO. Lo stato della mitigazione delle vulnerabilit\u00e0 pu\u00f2 essere valutato su queste pagine: Ubuntu, SUSE, RHEL, Debian. <\/p>\n
Per affrontare i problemi legati alla distribuzione di certificati revocati, si prevede di implementare in futuro il meccanismo SBAT (UEFI Secure Boot Advanced Targeting), il cui supporto \u00e8 stato realizzato per GRUB2, shim e fwupd, e che sar\u00e0 utilizzato a partire dai prossimi aggiornamenti invece 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, i quali includono informazioni su produttore, prodotto, componente e versione. Questi metadati sono firmati digitalmente e possono essere ulteriormente inclusi nelle liste di componenti autorizzati o vietati per il Secure Boot UEFI. In questo modo, SBAT consentir\u00e0 di gestire i numeri di versione dei componenti durante un'eventuale revoca senza la necessit\u00e0 di rigenerare le chiavi per Secure Boot e senza dover creare nuove firme per il kernel, shim, grub2 e fwupd. <\/p>\n
Vulnerabilit\u00e0 identificate: <\/p>\n
\n
CVE-2020-14372 \u2014 tramite il comando acpi in GRUB2, un utente privilegiato del sistema locale pu\u00f2 caricare tabelle ACPI modificate, posizionando il SSDT (Secondary System Description Table) nella directory \/boot\/efi e modificando le impostazioni in grub.cfg. Nonostante l'attivazione della modalit\u00e0 Secure Boot, il SSDT proposto verr\u00e0 eseguito dal kernel e pu\u00f2 essere utilizzato per disattivare la protezione LockDown, che blocca i percorsi di bypass del Secure Boot UEFI. Di conseguenza, l'attaccante potrebbe caricare il proprio modulo del kernel o eseguire codice tramite il meccanismo kexec, senza controllare la firma digitale.\n
CVE-2020-25632 \u2014 accesso a un'area di memoria gi\u00e0 liberata (use-after-free) nell'implementazione del comando rmmod, manifestandosi quando si tenta di scaricare qualsiasi modulo senza considerare le relative dipendenze. Questa vulnerabilit\u00e0 non esclude la creazione di un exploit che potrebbe portare all'esecuzione di codice bypassando la verifica del Secure Boot.\n
CVE-2021-20233 — possibilit\u00e0 di scrivere dati oltre il limite del buffer a causa di un calcolo errato della dimensione del buffer durante l'uso delle virgolette. Nel calcolo della dimensione si presumeva che per l'escaping di un apostrofo fossero necessari tre caratteri, mentre in realt\u00e0 ne servono quattro. <\/ul>\n