{"id":122049,"date":"2025-02-22T02:22:05","date_gmt":"2025-02-22T00:22:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-zagruzchike-grub2-vyyavlena-21-uyazvimost"},"modified":"2025-02-22T02:22:05","modified_gmt":"2025-02-22T00:22:05","slug":"v-zagruzchike-grub2-vyyavlena-21-uyazvimost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/v-zagruzchike-grub2-vyyavlena-21-uyazvimost","title":{"rendered":"Sono state identificate 21 vulnerabilit\u00e0 nel bootloader GRUB2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Pubblicate informazioni su 21 vulnerabilit\u00e0 nel bootloader GRUB2, la maggior parte delle quali porta a un buffer overflow e pu\u00f2 essere sfruttata per aggirare il meccanismo di verifica del boot UEFI Secure Boot. Al momento, i problemi sono stati risolti solo tramite patch. Lo stato della risoluzione delle vulnerabilit\u00e0 nelle distribuzioni pu\u00f2 essere valutato su queste pagine: Debian, Ubuntu, SUSE, RHEL, Fedora. Per risolvere i problemi in GRUB2 non \u00e8 sufficiente aggiornare solo il pacchetto, \u00e8 necessario anche generare nuove firme digitali interne e aggiornare installatori, bootloader, pacchetti del kernel, firmware fwupd e la layer shim. <\/p>\n
Vulnerabilit\u00e0 identificate: <\/p>\n
\n
CVE-2024-45774: scrittura oltre il limite del buffer durante l'analisi di immagini JPEG appositamente formattate.\n
CVE-2024-45776, CVE-2024-45777: overflow di interi durante la lettura di file mo appositamente formati, che porta a scritture oltre il limite del buffer.\n
CVE-2024-45778, CVE-2024-45779: overflow di interi durante l'elaborazione di un file system BFS danneggiato, che porta a un buffer overflow.\n
CVE-2024-45780: overflow di interi durante la gestione di archivi tar appositamente formati, che porta a scritture oltre il limite del buffer.\n
CVE-2024-45781, CVE-2025-0677: overflow del buffer durante l'operazione con un file system UFS danneggiato.\n
CVE-2024-45782, CVE-2025-1125: overflow del buffer durante il montaggio di una partizione HFS appositamente creata.\n
CVE-2025-0622: accesso alla memoria dopo la sua liberazione durante le operazioni con i moduli, che pu\u00f2 portare all'esecuzione di codice malevolo.\n
CVE-2025-0624: overflow del buffer durante il boot da rete.\n
CVE-2025-0678: overflow del buffer durante l'operazione con un file system Squash4 danneggiato.\n
CVE-2025-0684: overflow del buffer durante le operazioni con i link simbolici nel file system Reiserfs.\n
CVE-2025-0685: overflow del buffer durante le operazioni con i link simbolici nel file system JFS.\n
CVE-2025-0685: overflow del buffer durante le operazioni con i link simbolici nel file system ROMFS.\n
CVE-2025-0689: overflow del buffer durante l'operazione con una partizione UDF appositamente modificata.\n
CVE-2025-0690: overflow del buffer durante la ricezione di dati appositamente formattati dalla tastiera.\n
CVE-2025-1118: bypass del modo di isolamento Lockdown e recupero di contenuti casuali dalla memoria tramite l'esecuzione del comando dump.\n
CVE-2024-45775: la mancanza di controllo del codice di errore durante l'allocazione della memoria nell'elaborazione degli argomenti forniti pu\u00f2 portare a un danneggiamento della tabella IVT (Interrupt Vector Table).\n
CVE-2024-45783: accesso a un puntatore nullo durante il montaggio di un filesystem HFS+ non valido. <\/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":"