{"id":149133,"date":"2025-11-21T17:11:55","date_gmt":"2025-11-21T15:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/6-uyazvimostej-v-zagruzchike-grub2-pozvolyayushhih-obojti-uefi-secure-boot"},"modified":"2025-11-21T17:11:55","modified_gmt":"2025-11-21T15:11:55","slug":"6-uyazvimostej-v-zagruzchike-grub2-pozvolyayushhih-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/6-uyazvimostej-v-zagruzchike-grub2-pozvolyayushhih-obojti-uefi-secure-boot","title":{"rendered":"6 vulnerabilit\u00e0 nel bootloader GRUB2 che consentono di bypassare UEFI Secure Boot.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
\u00c8 stato pubblicato un pacchetto di patch che risolve 6 vulnerabilit\u00e0 nel bootloader GRUB2, la maggior parte delle quali porta a un accesso alla memoria dopo che \u00e8 stata liberata (use-after-free). I problemi potenzialmente identificati possono essere sfruttati per bypassare il meccanismo di verifica dell'avvio UEFI Secure Boot. Lo stato della risoluzione delle vulnerabilit\u00e0 nei vari distributivi pu\u00f2 essere valutato nelle seguenti pagine: Debian, Ubuntu, SUSE, RHEL, Arch e Fedora. Per risolvere i problemi in GRUB2 non \u00e8 sufficiente aggiornare il pacchetto, \u00e8 necessario anche generare nuove firme digitali interne e aggiornare gli installer, i bootloader, i pacchetti del kernel, i firmware fwupd e il layer shim. <\/p>\n
Vulnerabilit\u00e0 identificate: <\/p>\n
\n
CVE-2025-61661 \u2014 scrittura oltre il buffer allocato nella funzione grub_usb_get_string(), che pu\u00f2 essere sfruttata durante l'elaborazione delle stringhe in codifica UTF-8 e UTF-16 inviate durante il collegamento di dispositivi USB. Il problema \u00e8 causato dal fatto che il buffer veniva allocato sulla base della dimensione della stringa indicata nel primo messaggio dal dispositivo USB, mentre la dimensione durante l'operazione di conversione della codifica veniva calcolata sulla base delle operazioni di lettura successive dal dispositivo USB. Di conseguenza, un dispositivo USB modificato, che restituisce inizialmente un valore di dimensione ridotto, pu\u00f2 essere utilizzato per un attacco.\n
CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 \u2014 mancata pulizia dei gestori dei comandi \u00abnormal\u00bb, \u00abnormal_exit\u00bb, \u00abnet_set_vlan\u00bb e \u00abgettext\u00bb durante il caricamento dei moduli \u00abnormal\u00bb, \u00abnet\u00bb e \u00abgettext\u00bb, che crea condizioni per l'accesso alla memoria dopo la sua liberazione (use-after-free) in caso di esecuzione dei comandi indicati dopo il caricamento dei relativi moduli. Vulnerabilit\u00e0 simili sono state trovate anche per i comandi \u00abfunctional_test\u00bb e \u00aball_functional_test\u00bb, ma non sono stati assegnati identificatori CVE, poich\u00e9 tali comandi fanno parte della libreria di test e non dovrebbero essere inclusi nelle compilazioni di produzione.\n
CVE-2025-54771 \u2014 errore nel conteggio dei riferimenti alle strutture \u00abfs\u00bb nella funzione grub_file_close(), che porta all'accesso alla memoria dopo la sua liberazione (use-after-free). <\/ul>\n
Nella maggior parte delle distribuzioni Linux, per il caricamento verificato in modalit\u00e0 UEFI Secure Boot viene utilizzato un piccolo strato shim, certificato digitalmente da Microsoft. Questo strato verifica GRUB2 con un proprio certificato, consentendo agli sviluppatori delle distribuzioni di non dover certificare ogni aggiornamento del kernel e di GRUB presso Microsoft. Le vulnerabilit\u00e0 in GRUB2 consentono l'esecuzione di codice personalizzato dopo la verifica riuscita dello shim, ma prima del caricamento del sistema operativo, infiltrandosi nella catena di fiducia in modalit\u00e0 Secure Boot attiva e assumendo il pieno controllo del processo di avvio, ad esempio per avviare un altro sistema operativo, modificare i componenti del sistema operativo e bypassare la protezione Lockdown. <\/p>\n
Per bloccare la vulnerabilit\u00e0 senza revocare la firma digitale, le distribuzioni possono utilizzare il meccanismo SBAT (UEFI Secure Boot Advanced Targeting), il cui supporto \u00e8 implementato per GRUB2, shim e fwupd nella maggior parte delle distribuzioni Linux popolari. SBAT \u00e8 stato sviluppato congiuntamente con Microsoft e prevede l'aggiunta, nei file eseguibili dei componenti UEFI, di metadati aggiuntivi, che includono informazioni sul produttore, prodotto, componente e versione. I metadati indicati vengono firmati digitalmente e possono essere inclusi separatamente nelle liste di componenti autorizzati o vietati per UEFI Secure Boot. <\/p>\n
SBAT consente di bloccare l'uso della firma digitale per singoli numeri di versione dei componenti senza 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), bens\u00ec avviene a livello di sostituzione della chiave interna per la generazione di firme e l'aggiornamento di GRUB2, shim e altri artefatti di avvio forniti nei sistemi operativi. Prima dell'implementazione di SBAT, l'aggiornamento della lista dei certificati revocati (dbx, UEFI Revocation List) era una condizione obbligatoria per un blocco completo delle vulnerabilit\u00e0, dato che un attaccante, indipendentemente dal sistema operativo utilizzato, poteva compromettere UEFI Secure Boot usando 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":"