{"id":104320,"date":"2022-06-08T15:36:43","date_gmt":"2022-06-08T13:36:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2022-06-08T15:36:43","modified_gmt":"2022-06-08T13:36:43","slug":"uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Vulnerabilit\u00e0 in GRUB2 che consentono di bypassare UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nel caricatore GRUB2 sono state corrette 7 vulnerabilit\u00e0 che consentono di bypassare il meccanismo UEFI Secure Boot e avviare codice non verificato, come ad esempio l'inserimento di malware che opera a livello di bootloader o kernel. Si segnala inoltre una vulnerabilit\u00e0 nello strato shim, che consente anch'essa di bypassare UEFI Secure Boot. Il gruppo di vulnerabilit\u00e0 \u00e8 stato soprannominato Boothole 3, in analogia a problemi simili gi\u00e0 identificati nel bootloader. <\/p>\n
Per risolvere i problemi in GRUB2 e shim, le distribuzioni potranno utilizzare il meccanismo SBAT (UEFI Secure Boot Advanced Targeting), il cui supporto \u00e8 stato implementato per GRUB2, shim e fwupd. SBAT \u00e8 stato sviluppato congiuntamente con Microsoft e implica l'aggiunta di metadati esecutivi ai file dei componenti UEFI, inclusi informazioni sul produttore, prodotto, componente e versione. I metadati specificati sono firmati digitalmente e possono essere inclusi separatamente nelle liste di componenti consentiti o vietati per UEFI Secure Boot. <\/p>\n
Nella maggior parte delle distribuzioni Linux, per la verifica dell'avvio in modalit\u00e0 UEFI Secure Boot, viene utilizzato un piccolo layer shim, firmato digitalmente da Microsoft. Questo layer verifica GRUB2 con un proprio certificato, consentendo agli sviluppatori delle distribuzioni di non dover firmare ogni aggiornamento del kernel e di GRUB con Microsoft. Vulnerabilit\u00e0 in GRUB2 possono consentire l'esecuzione di codice non autorizzato dopo la verifica riuscita dello shim, ma prima dell'avvio del sistema operativo, infiltrandosi nella catena di fiducia con Secure Boot attivo e ottenendo il controllo completo del processo di avvio, inclusi l'avvio di un altro sistema operativo, la modifica dei componenti del sistema e il bypass delle protezioni Lockdown. <\/p>\n
Per risolvere i problemi nel bootloader, le distribuzioni dovranno generare nuove firme digitali interne e aggiornare installatori, bootloader, pacchetti kernel, firmware fwupd e lo strato shim. Prima dell'implementazione di SBAT, l'aggiornamento della lista dei certificati revocati (dbx, UEFI Revocation List) era una condizione necessaria per il blocco completo della vulnerabilit\u00e0, poich\u00e9 un attaccante, indipendentemente dal sistema operativo in uso, poteva compromettere UEFI Secure Boot utilizzando un supporto di avvio con una vecchia versione vulnerabile di GRUB2, firmata digitalmente. <\/p>\n
Invece di revocare le firme, SBAT consente di bloccarne l'uso per versioni specifiche dei componenti senza la necessit\u00e0 di revocare le chiavi per Secure Boot. Il blocco delle vulnerabilit\u00e0 tramite SBAT non richiede l'uso della lista dei certificati revocati UEFI (dbx), ma \u00e8 effettuato a livello di sostituzione della chiave interna per la generazione delle firme e l'aggiornamento di GRUB2, shim e altri artefatti di avvio forniti dalle distribuzioni. Attualmente, il supporto per SBAT \u00e8 gi\u00e0 stato aggiunto alla maggior parte delle distribuzioni Linux pi\u00f9 popolari. <\/p>\n
Vulnerabilit\u00e0 identificate: <\/p>\n
\n
CVE-2021-3696, CVE-2021-3695 \u2013 overflow del buffer nella heap durante l'elaborazione di immagini PNG formattate in modo specifico, che in teoria potrebbe essere utilizzato per eseguire codice malevolo e bypassare UEFI Secure Boot. Si osserva che il problema \u00e8 difficile da sfruttare, poich\u00e9 per creare un exploit funzionante \u00e8 necessario considerare un gran numero di fattori e avere conoscenze sulla disposizione della memoria.\n
CVE-2021-3697 \u2013 overflow attraverso il limite inferiore del buffer (buffer underflow) nel codice di elaborazione delle immagini JPEG. Sfruttare il problema richiede informazione sulla disposizione della memoria ed \u00e8 di complessit\u00e0 simile al problema con le immagini PNG (CVSS 7.5).\n
CVE-2022-28733 \u2014 overflow intero nella funzione grub_net_recv_ip4_packets(), che consente di influenzare il parametro rsm->total_len tramite l'invio di un pacchetto IP opportunamente formattato. Il problema \u00e8 stato segnalato come il pi\u00f9 grave tra le vulnerabilit\u00e0 elencate (CVSS 8.1). In caso di sfruttamento riuscito, la vulnerabilit\u00e0 consente di scrivere dati oltre il limite del buffer attraverso l'allocazione di memoria di dimensioni inferiori rispetto a quelle necessarie.\n
CVE-2022-28734 \u2014 overflow di un byte nel buffer durante l'elaborazione di intestazioni HTTP separate. Questo problema pu\u00f2 portare alla corruzione dei metadati GRUB2 (scrittura di un byte nullo immediatamente dopo la fine del buffer) quando si analizzano richieste HTTP opportunamente formattate.\n
CVE-2022-28735 \u2014 problema nel verificatore shim_lock che consente di caricare file non correlati al kernel. Questa vulnerabilit\u00e0 pu\u00f2 essere utilizzata per caricare, in modalit\u00e0 UEFI Secure Boot, moduli del kernel non firmati digitalmente o codice non verificato.\n
CVE-2022-28736 \u2014 accesso a un'area di memoria gi\u00e0 liberata nella funzione grub_cmd_chainloader() attraverso la ri-esecuzione del comando chainloader, utilizzato per caricare sistemi operativi non supportati in GRUB2. Lo sfruttamento pu\u00f2 portare all'esecuzione del codice dell'attaccante se l'aggressore \u00e8 in grado di determinare le caratteristiche della distribuzione della memoria in GRUB2.\n
CVE-2022-28737 \u2014 overflow del buffer nel layer shim, che si verifica nella funzione handle_image() durante il caricamento ed esecuzione di immagini EFI opportunamente formattate. <\/ul>\n