From 736925c843c56ebb8e7b2f1251512b26e4c90589 Mon Sep 17 00:00:00 2001 From: Luca Monducci Date: Tue, 11 Aug 2020 13:30:26 +0200 Subject: add italian translation --- .../security/2020-GRUB-UEFI-SecureBoot/Makefile | 1 + .../security/2020-GRUB-UEFI-SecureBoot/index.wml | 313 +++++++++++++++++++++ 2 files changed, 314 insertions(+) create mode 100644 italian/security/2020-GRUB-UEFI-SecureBoot/Makefile create mode 100644 italian/security/2020-GRUB-UEFI-SecureBoot/index.wml diff --git a/italian/security/2020-GRUB-UEFI-SecureBoot/Makefile b/italian/security/2020-GRUB-UEFI-SecureBoot/Makefile new file mode 100644 index 00000000000..03de1f8c0f7 --- /dev/null +++ b/italian/security/2020-GRUB-UEFI-SecureBoot/Makefile @@ -0,0 +1 @@ +include $(subst webwml/italian,webwml/english,$(CURDIR))/Makefile diff --git a/italian/security/2020-GRUB-UEFI-SecureBoot/index.wml b/italian/security/2020-GRUB-UEFI-SecureBoot/index.wml new file mode 100644 index 00000000000..fdbcd2d7413 --- /dev/null +++ b/italian/security/2020-GRUB-UEFI-SecureBoot/index.wml @@ -0,0 +1,313 @@ +#use wml::debian::template title="Vulnerabilità UEFI SecureBoot con GRUB2: BootHole" +#use wml::debian::translation-check translation="9c47c948da90cea57112872aa23f03da3a967d7b" + +

+Gli sviluppatori di Debian e di altri progetti nella comunità Linux sono +recentemente venuti a conoscenza di un grave problema nel bootloader GRUB2 +che consente di aggirare completamente l'UEFI SecureBoot. Tutti i dettagli +sul problema sono descritti nell'bollettino di sicurezza Debian +4735. Lo scopo di questo documento è spiegare le conseguenze di questa +vulnerabilità della sicurezza e quali passi devono essere fatti per +affrontarla. +

+ + + +

Premessa: cos'è UEFI SecureBoot?

+ +

+Lo UEFI Secure Boot (SB) è un meccanismo di verifica che assicura che il +codice eseguito da un computer con firmware UEFI sia attendibile. È +progettato per proteggere un sistema dal caricamento e dall'esecuzione +di codice malevolo nelle prime fasi del processo di avvio, prima che sia +caricato il sistema operativo. +

+ +

+SB funziona utilizzando somme di controllo e firme crittografiche. Ogni +programma che viene caricato dal firmware contiene una firma e una +somma di controllo, prima che ne sia concessa l'esecuzione il firmware +controlla che il programma sia attendibile validandone la somma di +controllo e la firma. Quando su un sistema è attivo il SB è impedito +qualunque tentativo di eseguire un programma non attendibile. Ciò +impedisce di eseguire codice inaspettato / non autorizzato nell'ambiente +UEFI. +

+ +

+La gran parte dell'hardware x86 viene precaricato dal costruttore con le +chiavi di Microsoft. Ciò comporta che il firmware di tali sistemi riterrà +attendibile i binari firmati da Microsoft. I sistemi più recenti sono +consegnati con il SB attivato, con le impostazioni predefinite non sono +in grado di eseguire codice non firmato tuttavia è possibile cambiare la +configurazione del firmware e disattivare il SB oppure registrare delle +chiavi di firma aggiuntive. +

+ +

+Debian, come molti altri sistemi operativi basati su Linux, utilizza un +programma chiamato shim per ampliare la fiducia del firmware agli altri +programmi che devono essere sicuri nella prima fase dell'avvio: il +bootloader GRUB2, il kernel Linux e gli strumenti per l'aggiornamento +del firmware (fwupd e fwupdate). +

+ +

Trovati dei bug in GRUB2

+ +

+Purtroppo è stato trovato un grave bug nel codice del bootloader GRUB2 quando +legge e analizza la propria configurazione (grub.cfg). Questo bug spezza la +catena della fiducia, sfruttando questo bug è possibile uscire dall'ambiente +protetto e caricare dei programmi non firmati nella prima fase di avvio. +Queste vulnerabilità è stata scoperta da dei ricercatori di Eclypsium e gli è +stato dato nome BootHole. +

+ +

+Anziché semplicemente correggere il bug, gli sviluppatori sono stati spinti +a fare un'accurata revisione del codice sorgente di GRUB2. Sarebbe stato +irresponsabile correggere una falla senza cercarne altre! Una squadra di +ingegneri hanno lavorato assieme per parecchie settimane per individuare e +sistemare una varietà di problemi. Sono stato trovati alcuni posti in cui, +con un input inaspettato, le allocazioni di memoria interna potevano andare +in overflow, in molti altri posti in cui calcoli matematici potevano andare +in overflow e causare problemi e in qualche altro posto in cui la memoria +avrebbe potuto essere utilizzata dopo che era stata liberata. Tutte le +correzioni sono state condivise e testate dalla comunità. +

+ +

+Nuovamente, consultare il bollettino +di sicurezza Debian 4735 per l'elenco completo dei problemi trovati. +

+ + +

Trovati dei bug anche in Linux

+ +

+Mentre si discuteva delle falle di GRUB2, gli sviluppatori hanno +parlato anche di due modi recentemente trovati da Jason A. Donenfeld +(zx2c4) (1, +2) +in cui anche Linux avrebbe potuto consentire di aggirare il Secure Boot. +Entrambi permettono a root di rimpiazzare le tabelle ACPI su un sistema +blindato nonostante ciò non debba essere permesso. Le correzioni sono già +state rilasciate per questi problemi. +

+ +

È necessario revocare le chiavi per riparare +la catena di Secure Boot

+ +

+Debian e gli altri produttori di sistemi operativi ovviamente rilasceranno le versioni corrette di GRUB2 e +Linux. Tuttavia ciò non è una soluzione completa a tutti i problemi visti. +Dei malintenzionati potrebbero essere ancora in grado di usare le vecchie +e vulnerabili versioni per aggirare il Secure Boot. +

+ +

+Per impedire ciò, il prossimo passo sarà per Microsoft di bloccare i binari +non sicuri in modo da impedirne l'esecuzione con SB. Questo si ottiene +utilizzando l'elenco DBX, una funzionalità prevista nel modello di +UEFI Secure Boot. A tutte le distribuzioni che contengono una copia di shim +firmata con le Microsoft è richiesto di fornire i dettagli dei binari o +delle chiavi coinvolte per facilitare questa procedura. Nella lista di revoca UEFI verranno +inserite queste informazioni. In un momento futuro, non ancora stabilito, +i sistemi inizieranno a utilizzare la lista aggiornata e rifiuteranno di +eseguire i binari vulnerabili con Secure Boot. +

+ +

+Il momento esatto in cui questo cambiamento verrà distribuito non è +ancora chiaro; a un certo punto i produttori di BIOS/UEFI includeranno la +nuova lista di revoca nelle nuove realizzazioni di firmware per il nuovo +hardware. Microsoft potrebbe anche rilasciare aggiornamenti per i +sistemi esistenti tramite Windows Update. Alcune distribuzioni Linux +potrebbero rilasciare aggiornamenti tramite il proprio processo per gli +aggiornamenti di sicurezza. Debian per adesso non lo fa, ma lo stiamo +valutando per il futuro. +

+ +

Quali sono gli effetti della revoca della chiave?

+ +

+Molti produttori sono cauti sull'applicare automaticamente degli +aggiornamenti che revocano le chiavi usate nel Secure Boot. Le installazioni +esistenti con SB attivo potrebbero immediatamente e assolutamente rifiutare +l'avvio a meno che l'utente sia stato attento e abbia installato anche tutti +gli aggiornamenti ai programmi. I sistemi con doppio avvio Windows/Linux +potrebbero improvvisamente nono avviare più Linux. I vecchi supporti per +l'installazione o di sistemi live naturalmente non riusciranno a partire, +potenzialmente facendo diventare più difficile il ripristino di un sistema. +

+ +

+Ci sono due modi ovvi per rimediare a un sistema che non si avvia: +

+ + + +

+Entrambe le soluzioni sembrano semplici ma ciascuna potrebbe richiedere +molto tempo agli utenti che hanno più sistemi. Inoltre prestare attenzione +al fatto che per attivare e disattivare il Secure Boot è necessario +l'accesso diretto alla macchina, normalmente non è possibile +cambiare questa configurazione al di fuori del firmware del computer. +Proprio per questo motivo le macchine server remote richiedono una +particolare attenzione. +

+ +

+Per queste ragioni si raccomanda caldamente a tutti gli utenti +Debian di prestare particolare attenzione a installare tutti gli aggiornamenti raccomandati per i propri +sistemi il prima possibile per ridurre la possibilità di avere problemi +in futuro. +

+ +

Pacchetti aggiornati

+ +

+Nota: i sistemi con Debian 9 (stretch) oppure una versione +più vecchia non riceveranno obbligatoriamente un aggiornamento, +perché Debian 10 (buster) è stato il primo rilascio di Debian a +includere il supporto per Secure Boot di UEFI. +

+ +

+Sono state aggiornate le versioni firmate di tutti i pacchetti, persino +di quelli che non avevamo bisogno di modifiche. Debian ha dovuto rigenerare +una nuova chiave/certificato per i propri pacchetti legati a Secure Boot. +Il precedente certificato era chiamato Debian Secure Boot Signer +(fingerprint +f156d24f5d4e775da0e6a9111f074cfce701939d688c64dba093f97753434f2c); +il nuovo è Debian Secure Boot Signer 2020 +(3a91a54f9f46a720fe5bbd2390538ba557da0c2ed5286f5351fe04fff254ec31). +

+ +

+Sono cinque i pacchetti sorgente in Debian che sono stati aggiornati per +Secure Boot di UEFI con le modifiche descritte di seguito: +

+ +

1. GRUB2

+ +

+Le versioni aggiornate dei pacchetti Debian GRUB2 sono adesso disponibili +tramite l'archivio debian-security per il rilascio stabile Debian 10 +(buster). Le versioni corrette saranno nel normale archivio delle +versioni di sviluppo di Debian (unstable e testing) molto presto. +

+ +

2. Linux

+ +

+Le versioni aggiornate dei pacchetti Debian linux sono adesso disponibili +tramite buster-proposed-updates per il rilascio stabile Debian 10 +(buster) e saranno inserite nel prossimo rilascio minore 10.5. +I nuovi pacchetti sono pure nell'archivio Debian delle versioni di +sviluppo (unstable e testing). Ci aspettiamo che presto i pacchetti con le +correzioni siano caricati in buster-backports. +

+ +

3. Shim

+ +

+Per come funziona la gestione delle chiavi per il Secure Boot di Debian, +non è necessario revocare i pacchetti di shim esistenti e firmati +da Microsoft. Tuttavia le versioni firmate dei pacchetti shim-helper +devono essere ricostruiti per usare la nuova chiava di firma. +

+ +

+Le versioni aggiornate dei pacchetti Debian shim sono adesso disponibili +tramite buster-proposed-updates per il rilascio stabile Debian 10 +(buster) e saranno inserite nel prossimo rilascio minore 10.5. +I nuovi pacchetti sono pure nell'archivio Debian delle versioni di +sviluppo (unstable e testing). +

+ +

4. Fwupdate

+ +

+Le versioni aggiornate dei pacchetti Debian fwupdate sono adesso disponibili +tramite buster-proposed-updates per il rilascio stabile Debian 10 +(buster) e saranno inserite nel prossimo rilascio minore 10.5. +Tempo fa il pacchetto fwupdate è stato rimosso da unstable e testing in +favore di fwupd. +

+ +

5. Fwupd

+ +

+Le versioni aggiornate dei pacchetti Debian fwupd sono adesso disponibili +tramite buster-proposed-updates per il rilascio stabile Debian 10 +(buster) e saranno inserite nel prossimo rilascio minore 10.5. +I nuovi pacchetti sono pure nell'archivio Debian delle versioni di +sviluppo (unstable e testing). +

+ +

Rilascio minore Debian 10.5 (buster), +supporti per l'installazione e live aggiornati

+ +

+Tutte le correzioni descritte sono destinate a essere incluse nel rilascio +minore Debian 10.5 (buster), previsto per il 1 agosto 2020. Di +conseguenza 10.5 dovrebbe essere la scelta obbligata per i supporti di +installazione e di sistemi live. In futuro le immagini precedenti potrebbero +non funzionare con Secure Boot quando le revoche saranno distribuite. +

+ +

Ulteriori informazioni

+ +

+Molte altre informazioni sulla configurazione di UEFI Secure Boot con Debian +sono nel wiki, consultare https://wiki.debian.org/SecureBoot.

+ +

+Altre risorse su questo argomento: +

+ + -- cgit v1.2.3