Svelate informazioni su 8 vulnerabilità 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.
Ricordiamo che nei principali distribuzioni Linux, per il boot verificato in modalità 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à 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à 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.
Come per la vulnerabilità BootHole dell'anno scorso, aggiornare semplicemente il bootloader non è sufficiente per risolvere il problema, poiché un attaccante, indipendentemente dal sistema operativo in uso, può 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à la possibilità di utilizzare vecchi supporti di installazione con Linux.
Nei sistemi con firmware in cui è stato aggiornato l'elenco dei certificati revocati, in modalità UEFI Secure Boot sarà 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é 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à può essere valutato su queste pagine: Ubuntu, SUSE, RHEL, Debian.
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 è stato realizzato per GRUB2, shim e fwupd, e che sarà utilizzato a partire dai prossimi aggiornamenti invece della funzionalità fornita dal pacchetto dbxtool. SBAT è 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à di gestire i numeri di versione dei componenti durante un'eventuale revoca senza la necessità di rigenerare le chiavi per Secure Boot e senza dover creare nuove firme per il kernel, shim, grub2 e fwupd.
Vulnerabilità identificate:
- CVE-2020-14372 — tramite il comando acpi in GRUB2, un utente privilegiato del sistema locale può caricare tabelle ACPI modificate posizionando l'SSDT (Secondary System Description Table) nella directory /boot/efi e modificando le impostazioni in grub.cfg. Nonostante l'attivazione della modalità Secure Boot, l'SSDT proposto sarà eseguito dal kernel e potrà essere utilizzato per disabilitare la protezione LockDown che blocca i percorsi di bypass del Secure Boot UEFI. Di conseguenza, l'attaccante può riuscire a caricare il proprio modulo kernel o eseguire codice tramite il meccanismo kexec, senza alcun controllo della firma digitale.
- CVE-2020-25632 — accesso a una zona di memoria già liberata (use-after-free) nell'implementazione del comando rmmod, che si manifesta quando si tenta di scaricare qualsiasi modulo senza considerare le dipendenze ad esso correlate. La vulnerabilità non esclude la creazione di un exploit, che potrebbe portare all'esecuzione di codice bypassando la verifica del Secure Boot.
- CVE-2020-25647 — write out of bounds in the function grub_usb_device_initialize(), called during the initialization of USB devices. The issue can be exploited by connecting a specially crafted USB device that provides parameters whose size does not match the size of the buffer allocated for USB structures. An attacker could achieve code execution that is not verified in Secure Boot by manipulating USB devices.
- CVE-2020-27749 — buffer overflow in the function grub_parser_split_cmdline(), which can be triggered by specifying GRUB2 command line variables larger than 1 KB. This vulnerability allows code execution bypassing Secure Boot.
- CVE-2020-27779 — the cutmem command allows an attacker to delete a range of addresses from memory to bypass Secure Boot.
- CVE-2021-3418 — changes in shim_lock created an additional vector for exploiting last year’s vulnerability CVE-2020-15705. When a certificate used for signing GRUB2 is added to dbx, GRUB2 allows any kernel to be loaded directly without signature verification.
- CVE-2021-20225 — a vulnerability allowing data to be written outside the buffer when executing commands with a very large number of options.
- CVE-2021-20233 - vulnerabilità di scrittura oltre il buffer a causa di un calcolo errato della dimensione del buffer durante l'uso delle virgolette. Nel calcolo della dimensione si presumeva che per sfuggire un apostrofo fosse necessario utilizzare tre simboli, mentre in realtà ne servivano quattro.
Fonte: opennet.ru
