{"id":105601,"date":"2022-11-16T21:37:02","date_gmt":"2022-11-16T19:37:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/dve-uyazvimosti-v-grub2-pozvolyayushhie-obojti-zashhitu-uefi-secure-boot"},"modified":"2022-11-16T21:37:02","modified_gmt":"2022-11-16T19:37:02","slug":"dve-uyazvimosti-v-grub2-pozvolyayushhie-obojti-zashhitu-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/dve-uyazvimosti-v-grub2-pozvolyayushhie-obojti-zashhitu-uefi-secure-boot","title":{"rendered":"Due vulnerabilit\u00e0 in GRUB2 consentono di bypassare la protezione UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Sono emerse informazioni su due vulnerabilit\u00e0 nel bootloader GRUB2 che possono portare all'esecuzione di codice utilizzando font appositamente progettati e nell'elaborazione di specifiche sequenze Unicode. Le vulnerabilit\u00e0 possono essere sfruttate per eludere il meccanismo di avvio verificato UEFI Secure Boot. <\/p>\n
La correzione \u00e8 stata pubblicata sotto forma di patch. \u00c8 possibile valutare lo stato di risoluzione delle vulnerabilit\u00e0 nei pacchetti distributivi sulle seguenti pagine: Ubuntu, SUSE, RHEL, Fedora, Debian. 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 la layer shim. <\/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 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":"