Mozilla espone per errore la chiave privata di Firefox e Thunderbird: cos'è successo

Le firme crittografiche accompagnano da molti anni la distribuzione del software e sono particolarmente importanti nel mondo Linux, dove amministratori e utenti possono verificare autonomamente l’origine di pacchetti, archivi e file di checksum. Mozilla usa infrastrutture di firma differenti a seconda dell’elemento.

In questi giorni è successo che una chiave GPG (GNU Privacy Guard) utilizzata per firmare gli archivi compressi tarball Linux, i pacchetti RPM e i file contenenti gli hash delle release di Firefox e Thunderbird sia comparsa per errore in un repository GitHub amministrato da Mozilla.

L’incidente non equivale, almeno sulla base delle verifiche comunicate dalla fondazione, a una compromissione accertata: i log disponibili non mostrano accessi da parte di soggetti non autorizzati e il repository risultava accessibile a un piccolo gruppo di dipendenti Mozilla che disponevano già legittimamente della chiave attraverso altri canali. La scelta, però, è stata quella più prudente: revoca della vecchia sottochiave, introduzione della nuova e aggiunta di protezioni per evitare che un episodio analogo possa ripetersi.

Che cosa è successo alla chiave utilizzata da Mozilla

Mozilla spiega che una copia non cifrata della precedente chiave privata di firma è stata accidentalmente inserita in un repository GitHub privato. Una chiave privata dovrebbe rimanere sotto controllo stretto perché consente, a chi ne entra in possesso, di creare firme che appaiono riconducibili al relativo titolare.

Se non è più possibile garantire con assoluta certezza che una chiave sia rimasta confinata esclusivamente nei sistemi previsti, la soluzione corretta consiste normalmente nel revocarla e sostituirla. E Mozilla ha seguito proprio questa strada.

La revoca rappresenta una dichiarazione crittografica: segnala ai software compatibili con OpenPGP che quella chiave, o in questo caso quella specifica sottochiave, non deve più essere considerata valida per verificare nuove firme. Non si tratta quindi semplicemente di pubblicare una chiave diversa e continuare come prima; bisogna distribuire anche l’informazione che rende inutilizzabile la vecchia credenziale.

OpenPGP permette di organizzare l’identità crittografica attorno a una chiave primaria alla quale si collegano una o più sottochiavi dedicate a operazioni specifiche. È una scelta pratica e di sicurezza: la chiave principale può rimanere maggiormente protetta, mentre le sottochiavi svolgono attività operative come la firma quotidiana dei file.

La chiave pubblica Mozilla Software Releases continua ad avere fingerprint 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353. A cambiare è la sottochiave usata per le nuove firme, identificata dal fingerprint 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3. Mozilla indica come data di scadenza il 5 agosto 2028.

Fedora 43 e successive: DNF gestisce quasi tutto

Sulle versioni moderne di Fedora la transizione è piuttosto semplice. Mozilla indica che con Fedora 43 e successive, il gestore di pacchetti DNF (Dandified Yum) scarica la chiave aggiornata durante il successivo aggiornamento e chiede all’utente di confermarne l’importazione.

Qui vale una regola che dovrebbe diventare automatica ogni volta che un package manager presenta una nuova chiave: non approvare alla cieca. Il fingerprint funziona come identificatore compatto della chiave pubblica e permette di accertare che quella proposta dal gestore dei pacchetti sia proprio la chiave annunciata da Mozilla.

L’operazione non richiede quindi la rimozione manuale della vecchia chiave. DNF nelle release più recenti è in grado di gestire correttamente la rotazione; resta all’utente il compito di controllare l’identificativo prima dell’accettazione.

Fedora 42, RHEL, Rocky Linux e AlmaLinux richiedono un passaggio in più

La situazione cambia con Fedora 42 e versioni precedenti e con alcune release di RHEL, Rocky Linux e AlmaLinux. I gestori dei pacchetti presenti su tali sistemi possono non riuscire a sostituire automaticamente la chiave già memorizzata.

Il sintomo è abbastanza evidente: DNF interrompe gli aggiornamenti con messaggi come “Import of the key didn’t help, wrong key?” oppure segnala che le chiavi GPG configurate per il repository Mozilla risultano già installate ma non sono corrette per il pacchetto.

Mozilla consiglia in tal caso di rimuovere prima la precedente chiave con  il comando sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353, importare quella aggiornata tramite sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg e infine pulire la cache con sudo dnf clean all.

La fondazione avverte che eseguire soltanto rpm --import lasciando la vecchia chiave installata può restituire apparentemente un risultato positivo senza aggiornare realmente la chiave utilizzata.

Anche openSUSE e SUSE possono bloccare gli aggiornamenti

Sui sistemi basati su openSUSE o SUSE il comportamento è simile. Zypper può non rimpiazzare autonomamente la vecchia chiave e la verifica delle firme può fallire con errori come “Signature verification failed” o “NOKEY“.

La procedura suggerita da Mozilla prevede la stessa eliminazione dal database RPM, seguita dall’importazione della nuova chiave. Alla fine si esegue sudo zypper refresh per aggiornare le informazioni provenienti dai repository.

Non si tratta di aggirare la verifica delle firme per far funzionare nuovamente gli aggiornamenti. Al contrario: si aggiorna l’elemento di fiducia utilizzato da RPM affinché le nuove release possano continuare a superare correttamente il controllo crittografico.

Perché una firma GPG è importante quando si scarica un software

Un hash come SHA-256 permette di verificare che un file non sia cambiato rispetto a un valore di riferimento: da solo, però, non dice chi abbia pubblicato quel valore e, di conseguenza, l’autore del file.

Una firma digitale aggiunge l’autenticazione: Mozilla calcola la firma utilizzando la chiave privata; chi possiede la corrispondente chiave pubblica può controllare che il file o il checksum provenga da chi controlla quella chiave e che i dati non siano cambiati dopo la firma.

Qui emerge anche la potenziale gravità della perdita di una chiave privata: chi riuscisse a ottenerla potrebbe firmare materiale malevolo facendo apparire valida la firma crittografica.