diff options
author | Luca Monducci <luca.mo@tiscali.it> | 2020-08-11 13:30:26 +0200 |
---|---|---|
committer | Luca Monducci <luca.mo@tiscali.it> | 2020-08-11 13:30:26 +0200 |
commit | 736925c843c56ebb8e7b2f1251512b26e4c90589 (patch) | |
tree | 393cdf0eee4bee8018b8d05dca01067d4c12b79d | |
parent | aa336253f717ab1e00e48b3a9c31fbf028e19324 (diff) |
add italian translation
-rw-r--r-- | italian/security/2020-GRUB-UEFI-SecureBoot/Makefile | 1 | ||||
-rw-r--r-- | italian/security/2020-GRUB-UEFI-SecureBoot/index.wml | 313 |
2 files changed, 314 insertions, 0 deletions
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: <q>BootHole</q>" +#use wml::debian::translation-check translation="9c47c948da90cea57112872aa23f03da3a967d7b" + +<p> +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'<a +href="$(HOME)/security/2020/dsa-4735">bollettino di sicurezza Debian +4735</a>. Lo scopo di questo documento è spiegare le conseguenze di questa +vulnerabilità della sicurezza e quali passi devono essere fatti per +affrontarla. +</p> + +<ul> + <li><b><a href="#what_is_SB">Premessa: cos'è UEFI SecureBoot?</a></b></li> + <li><b><a href="#grub_bugs">Trovati dei bug in GRUB2</a></b></li> + <li><b><a href="#linux_bugs">Trovati dei bug anche in Linux</a></b></li> + <li><b><a href="#revocations">È necessario revocare le chiavi per riparare la catena di Secure Boot</a></b></li> + <li><b><a href="#revocation_problem">Quali sono gli effetti della revoca della chiave?</a></b></li> + <li><b><a href="#package_updates">Pacchetti aggiornati</a></b> + <ul> + <li><b><a href="#grub_updates">1. GRUB2</a></b></li> + <li><b><a href="#linux_updates">2. Linux</a></b></li> + <li><b><a href="#shim_updates">3. Shim</a></b></li> + <li><b><a href="#fwupdate_updates">4. Fwupdate</a></b></li> + <li><b><a href="#fwupd_updates">5. Fwupd</a></b></li> + </ul></li> + <li><b><a href="#buster_point_release">Rilascio minore Debian 10.5 + (<q>buster</q>), supporti per l'installazione e live + aggiornati</a></b></li> + <li><b><a href="#more_info">Ulteriori informazioni</a></b></li> +</ul> + +<h1><a name="what_is_SB">Premessa: cos'è UEFI SecureBoot?</a></h1> + +<p> +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. +</p> + +<p> +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. +</p> + +<p> +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. +</p> + +<p> +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). +</p> + +<h1><a name="grub_bugs">Trovati dei bug in GRUB2</a></h1> + +<p> +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 <b><a +href="https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/">BootHole</a></b>. +</p> + +<p> +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à. +</p> + +<p> +Nuovamente, consultare il <a href="$(HOME)/security/2020/dsa-4735">bollettino +di sicurezza Debian 4735</a> per l'elenco completo dei problemi trovati. +</p> + + +<h1><a name="linux_bugs">Trovati dei bug anche in Linux</a></h1> + +<p> +Mentre si discuteva delle falle di GRUB2, gli sviluppatori hanno +parlato anche di due modi recentemente trovati da Jason A. Donenfeld +(zx2c4) (<a +href="https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language.sh">1</a>, +<a href="https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh">2</a>) +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. +</p> + +<h1><a name="revocations">È necessario revocare le chiavi per riparare +la catena di Secure Boot</a></h1> + +<p> +Debian e gli altri produttori di sistemi operativi ovviamente <a +href="#package_updates">rilasceranno le versioni corrette</a> 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. +</p> + +<p> +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 <b>DBX</b>, 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 <a +href="https://uefi.org/revocationlistfile">lista di revoca UEFI</a> verranno +inserite queste informazioni. In un momento futuro, <b>non ancora stabilito</b>, +i sistemi inizieranno a utilizzare la lista aggiornata e rifiuteranno di +eseguire i binari vulnerabili con Secure Boot. +</p> + +<p> +Il momento <i>esatto</i> 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 <b>potrebbe</b> 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 <b>per adesso</b> non lo fa, ma lo stiamo +valutando per il futuro. +</p> + +<h1><a name="revocation_problem">Quali sono gli effetti della revoca della chiave?</a></h1> + +<p> +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. +</p> + +<p> +Ci sono due modi ovvi per rimediare a un sistema che non si avvia: +</p> + +<ul> +<li>Riavviare in modalità <q>ripristino</q> (rescue) tramite un <a +href="#buster_point_release">supporto per l'installazione recente</a> e +applicare gli aggiornamenti da quello; oppure</li> +<li>Disattivare temporaneamente il Secure Boot per ottenere di nuovo accesso +al sistema, applicare gli aggiornamenti e riattivarlo.</li> +</ul> + +<p> +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 <b>non</b> è possibile +cambiare questa configurazione al di fuori del firmware del computer. +Proprio per questo motivo le macchine server remote richiedono una +particolare attenzione. +</p> + +<p> +Per queste ragioni si raccomanda caldamente a <b>tutti</b> gli utenti +Debian di prestare particolare attenzione a installare tutti gli <a +href="#package_updates">aggiornamenti raccomandati</a> per i propri +sistemi il prima possibile per ridurre la possibilità di avere problemi +in futuro. +</p> + +<h1><a name="package_updates">Pacchetti aggiornati</a></h1> + +<p> +<b>Nota:</b> i sistemi con Debian 9 (<q>stretch</q>) oppure una versione +più vecchia <b>non</b> riceveranno obbligatoriamente un aggiornamento, +perché Debian 10 (<q>buster</q>) è stato il primo rilascio di Debian a +includere il supporto per Secure Boot di UEFI. +</p> + +<p> +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 <q>Debian Secure Boot Signer</q> +(fingerprint +<code>f156d24f5d4e775da0e6a9111f074cfce701939d688c64dba093f97753434f2c</code>); +il nuovo è <q>Debian Secure Boot Signer 2020</q> +(<code>3a91a54f9f46a720fe5bbd2390538ba557da0c2ed5286f5351fe04fff254ec31</code>). +</p> + +<p> +Sono cinque i pacchetti sorgente in Debian che sono stati aggiornati per +Secure Boot di UEFI con le modifiche descritte di seguito: +</p> + +<h2><a name="grub_updates">1. GRUB2</a></h2> + +<p> +Le versioni aggiornate dei pacchetti Debian GRUB2 sono adesso disponibili +tramite l'archivio debian-security per il rilascio stabile Debian 10 +(<q>buster</q>). Le versioni corrette saranno nel normale archivio delle +versioni di sviluppo di Debian (unstable e testing) molto presto. +</p> + +<h2><a name="linux_updates">2. Linux</a></h2> + +<p> +Le versioni aggiornate dei pacchetti Debian linux sono adesso disponibili +tramite buster-proposed-updates per il rilascio stabile Debian 10 +(<q>buster</q>) 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. +</p> + +<h2><a name="shim_updates">3. Shim</a></h2> + +<p> +Per come funziona la gestione delle chiavi per il Secure Boot di Debian, +<b>non</b> è 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. +</p> + +<p> +Le versioni aggiornate dei pacchetti Debian shim sono adesso disponibili +tramite buster-proposed-updates per il rilascio stabile Debian 10 +(<q>buster</q>) e saranno inserite nel prossimo rilascio minore 10.5. +I nuovi pacchetti sono pure nell'archivio Debian delle versioni di +sviluppo (unstable e testing). +</p> + +<h2><a name="fwupdate_updates">4. Fwupdate</a></h2> + +<p> +Le versioni aggiornate dei pacchetti Debian fwupdate sono adesso disponibili +tramite buster-proposed-updates per il rilascio stabile Debian 10 +(<q>buster</q>) e saranno inserite nel prossimo rilascio minore 10.5. +Tempo fa il pacchetto fwupdate è stato rimosso da unstable e testing in +favore di fwupd. +</p> + +<h2><a name="fwupd_updates">5. Fwupd</a></h2> + +<p> +Le versioni aggiornate dei pacchetti Debian fwupd sono adesso disponibili +tramite buster-proposed-updates per il rilascio stabile Debian 10 +(<q>buster</q>) e saranno inserite nel prossimo rilascio minore 10.5. +I nuovi pacchetti sono pure nell'archivio Debian delle versioni di +sviluppo (unstable e testing). +</p> + +<h1><a name="buster_point_release">Rilascio minore Debian 10.5 (<q>buster</q>), +supporti per l'installazione e live aggiornati</a></h1> + +<p> +Tutte le correzioni descritte sono destinate a essere incluse nel rilascio +minore Debian 10.5 (<q>buster</q>), 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. +</p> + +<h1><a name="more_info">Ulteriori informazioni</a></h1> + +<p> +Molte altre informazioni sulla configurazione di UEFI Secure Boot con Debian +sono nel wiki, consultare <a +href="https://wiki.debian.org/SecureBoot">https://wiki.debian.org/SecureBoot</a>.</p> + +<p> +Altre risorse su questo argomento: +</p> + +<ul> + <li><a href="https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/">Articolo + di Eclypsium <q>BootHole</q></a> in cui sono descritte le vulnerabilità + trovate</li> + <li><a href="https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011">Microsoft + Guidance for Addressing Security Feature Bypass in GRUB</a></li> + <li><a href="https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass">Articolo + della KnowledgeBase di Ubuntu</a></li> + <li><a href="https://access.redhat.com/security/vulnerabilities/grub2bootloader">Articolo + di Red Hat sulla vulnerabilità</a></li> + <li><a href="https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/">Articolo + di SUSE sulla vulnerabilità</a></li> +</ul> |