{"id":110421,"date":"2023-10-04T09:10:18","date_gmt":"2023-10-04T07:10:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-ntfs-drajvere-iz-sostava-grub2-pozvolyayushhaya-vypolnit-kod-i-obojti-uefi-secure-boot"},"modified":"2023-10-04T09:10:18","modified_gmt":"2023-10-04T07:10:18","slug":"uyazvimost-v-ntfs-drajvere-iz-sostava-grub2-pozvolyayushhaya-vypolnit-kod-i-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/uyazvimost-v-ntfs-drajvere-iz-sostava-grub2-pozvolyayushhaya-vypolnit-kod-i-obojti-uefi-secure-boot","title":{"rendered":"Vulnerabilit\u00e0 nel driver NTFS di GRUB2 che consente l'esecuzione di codice e il bypass di UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nel driver che gestisce il file system NTFS nel bootloader GRUB2 \u00e8 stata individuata una vulnerabilit\u00e0 (CVE-2023-4692) che consente di eseguire codice personalizzato a livello di bootloader quando si accede a un'immagine di file system appositamente formattata. Questa vulnerabilit\u00e0 pu\u00f2 essere sfruttata per eludere il meccanismo di avvio verificato UEFI Secure Boot. <\/p>\n
La vulnerabilit\u00e0 \u00e8 causata da un errore nel codice di parsing dell'attributo NTFS «$ATTRIBUTE_LIST» (grub-core\/fs\/ntfs.c), che pu\u00f2 essere sfruttato per scrivere informazioni controllate dall'utente in un'area di memoria al di fuori del buffer allocato. Durante l'elaborazione di un'immagine NTFS appositamente formattata, il buffer overflow porta alla sovrascrittura di parte della memoria di GRUB e, in determinate condizioni, alla corruzione dell'area di memoria del firmware UEFI, consentendo potenzialmente l'esecuzione di codice proprio a livello di bootloader o firmware. <\/p>\n
Inoltre, nel driver NTFS di GRUB2 \u00e8 stata identificata un'altra vulnerabilit\u00e0 (CVE-2023-4693) che consente di leggere il contenuto di un'area di memoria arbitraria durante il parsing dell'attributo «$DATA» in un'immagine NTFS appositamente formattata. Tra le altre cose, questa vulnerabilit\u00e0 consente di estrarre dati riservati memorizzati nella memoria o di determinare i valori delle variabili EFI. <\/p>\n
I problemi sono stati finora risolti solo tramite una patch. \u00c8 possibile valutare lo stato della correzione delle vulnerabilit\u00e0 nelle distribuzioni su queste pagine: Debian, Ubuntu, SUSE, RHEL, Fedora. Per risolvere i problemi in GRUB2, non \u00e8 sufficiente aggiornare semplicemente il pacchetto; \u00e8 necessario anche generare nuove firme digitali interne e aggiornare gli installatori, i bootloader, i pacchetti del kernel, i firmware fwupd e il layer shim. <\/p>\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 delle firme digitali 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 dell'elenco dei certificati revocati UEFI (dbx) ed \u00e8 effettuato a livello di sostituzione della chiave interna per la creazione di firme e nell'aggiornamento di GRUB2, shim e altri artefatti di avvio forniti dalle distribuzioni. Prima dell'implementazione di SBAT, l'aggiornamento dell'elenco 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 utilizzato, poteva compromettere UEFI Secure Boot utilizzando il bootloader. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"