{"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\/news\/v-zagruzchike-grub2-vyyavlena-21-uyazvimost","title":{"rendered":"Sono state rilevate 21 vulnerabilit\u00e0 nel bootloader GRUB2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Sono state pubblicate informazioni su 21 vulnerabilit\u00e0 nel bootloader GRUB2, la maggior parte delle quali porta a overflow del buffer e possono essere utilizzate per eludere il meccanismo di verifica dell'avvio UEFI Secure Boot. I problemi sono attualmente risolti solo in forma di patch. Lo stato di risoluzione delle vulnerabilit\u00e0 nelle distribuzioni pu\u00f2 essere valutato nelle seguenti pagine: Debian, Ubuntu, SUSE, RHEL, 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-2024-45774: scrittura oltre il limite del buffer durante l'analisi di immagini JPEG appositamente formattate.\n
CVE-2024-45776, CVE-2024-45777: overflow integer durante la lettura di mo-file appositamente formattati, portando a scritture oltre il buffer.\n
CVE-2024-45778, CVE-2024-45779: overflow integer durante l'interazione con un filesystem BFS corrotto, causando overflow del buffer.\n
CVE-2024-45780: overflow integer durante l'elaborazione di archivi tar appositamente formattati, conducendo a scritture oltre il limite del buffer.\n
CVE-2024-45781, CVE-2025-0677: overflow del buffer durante l'interazione con un filesystem UFS corrotto.\n
CVE-2024-45782, CVE-2025-1125: overflow del buffer durante il montaggio di una partizione HFS appositamente formattata.\n
CVE-2025-0622: accesso alla memoria dopo il suo rilascio durante la manipolazione dei moduli, pu\u00f2 portare all'esecuzione di codice da parte dell'attaccante.\n
CVE-2025-0624: overflow del buffer durante il boot da rete.\n
CVE-2025-0678: overflow del buffer durante l'interazione con un filesystem Squash4 corrotto.\n
CVE-2025-0684: overflow del buffer durante la manipolazione di link simbolici nel filesystem Reiserfs.\n
CVE-2025-0685: overflow del buffer durante la manipolazione di link simbolici nel filesystem JFS.\n
CVE-2025-0685: overflow del buffer durante la manipolazione di link simbolici nel filesystem ROMFS.\n
CVE-2025-0689: overflow del buffer durante l'interazione con una partizione UDF appositamente modificata.\n
CVE-2025-0690: overflow del buffer durante l'ottenimento di dati appositamente formattati dalla tastiera.\n
CVE-2025-1118: elusione della modalit\u00e0 di isolamento Lockdown e estrazione di contenuti arbitrari dalla memoria tramite l'esecuzione del comando dump.\n
CVE-2024-45775: mancanza di controllo del codice di errore durante l'allocazione di memoria durante l'analisi degli argomenti forniti pu\u00f2 portare a danneggiamenti dei dati IVT (Interrupt Vector Table).\n
CVE-2024-45783: access tramite puntatore nullo durante il montaggio di un file system HFS+ non valido. <\/ul>\n
In gran parte delle distribuzioni Linux, per il processo di avvio verificato in modalit\u00e0 UEFI Secure Boot viene utilizzato un piccolo layer shim, firmato digitalmente da Microsoft. Questo layer verifica GRUB2 con il proprio certificato, permettendo agli sviluppatori delle distribuzioni di non dover firmare ogni aggiornamento del kernel e di GRUB con Microsoft. Le vulnerabilit\u00e0 in GRUB2 consentono di eseguire codice personalizzato dopo una verifica riuscita del shim, ma prima del caricamento del sistema operativo, infiltrandosi nella catena di fiducia durante il funzionamento del Secure Boot e ottenendo il controllo completo sul successivo processo di avvio, ad esempio, per caricare un altro sistema operativo, modificare componenti del sistema operativo e bypassare la protezione Lockdown. <\/p>\n
Per bloccare la vulnerabilit\u00e0 senza revocare la firma digitale, i distributori possono utilizzare il meccanismo SBAT (UEFI Secure Boot Advanced Targeting), il cui supporto \u00e8 stato implementato per GRUB2, shim e fwupd nella maggior parte dei distribuiti Linux. SBAT \u00e8 stato sviluppato congiuntamente a Microsoft e implica l'aggiunta di metadati ai file eseguibili dei componenti UEFI, che includono informazioni sul produttore, prodotto, componente e versione. I metadati indicati sono firmati digitalmente e possono essere inclusi separatamente nelle liste di componenti consentiti 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 dover revocare le chiavi per il Secure Boot. Il blocco delle vulnerabilit\u00e0 tramite SBAT non richiede l'uso dell'elenco dei certificati revocati UEFI (dbx), ma avviene a livello di sostituzione della chiave interna per la generazione delle firme e l'aggiornamento di GRUB2, shim e altri artefatti di avvio forniti dai pacchetti. Prima dell'implementazione di SBAT, l'aggiornamento dell'elenco dei certificati revocati (dbx, UEFI Revocation List) era una condizione necessaria per il blocco completo delle vulnerabilit\u00e0, poich\u00e9 un attaccante, indipendentemente dal sistema operativo utilizzato, poteva compromettere il Secure Boot UEFI utilizzando un supporto di avvio con una vecchia versione vulnerabile di GRUB2, certificata con una firma digitale. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"