Zum Inhalt springen
Beveiligingsnieuws

Mozilla widerruft Firefox- und Thunderbird-Signing-Key

Firefox Linux signing key

Mozilla hat für Linux den kryptografischen Signing-Key widerrufen, der für die Download-Pakete von Firefox und Thunderbird verwendet wird. Der Auslöser: Ein unverschärftes Exemplar des Keys wurde versehentlich in einem internen, privaten Code-Repository abgelegt. Damit ist der Widerruf nötig, um die Integrität von Signaturen künftig zuverlässig zu gewährleisten. Für viele Nutzer ändert sich zwar nichts – aber bei einzelnen Prüf- oder Installationswegen kann es zu Problemen kommen.

Im Kern geht es um die Frage: Wer signiert die heruntergeladenen Archive – und wurde nichts daran manipuliert? Der alte Signing-Key diente genau dieser Bestätigung. Sobald ein Widerruf importiert wird, verlieren Signaturen, die mit dem alten Key erstellt wurden, ihren Verifizierungsstatus. Das betrifft nicht nur zukünftige Downloads, sondern auch ältere Versionen, die man eventuell noch überprüft.

Warum Mozilla den Signing-Key widerrufen hat

Mozilla beschreibt, dass der betreffende Key nach einem Versehen in eine private Codeumgebung gelangte. Ein solcher Key ist essenziell, weil Anwender oder Linux-Distributionen damit prüfen, ob ein heruntergeladenes Firefox- oder Thunderbird-Paket tatsächlich aus Mozillas Build-Prozess stammt und nicht nachträglich verändert wurde.

Auch wenn bislang nichts darauf hindeutet, dass Unbefugte außerhalb des Unternehmens Zugriff erlangten, handelt Mozilla konsequent: Der Key wird widerrufen, damit künftig keine Signaturen mit dem kompromittierbar gewordenen Material als gültig durchgehen. Mozilla betont außerdem, dass das Repository private Zugriffsrechte hatte und die Einsicht zumindest denjenigen vorbehalten war, die ohnehin berechtigten Zugriff hatten.

Wer ist betroffen – und wer muss nichts tun?

Für den Großteil der Nutzer gilt: Sie müssen vermutlich nichts unternehmen. Viele Installationsroutinen und Update-Mechanismen holen sich bereits die passenden Schlüssel, sobald sie Änderungen an der Signaturprüfung erkennen.

Mozilla nennt jedoch zwei Gruppen, bei denen Handlungsbedarf entstehen kann:

  • Nutzer, die Signaturen manuell prüfen: In diesem Fall müssen sie den neuen Subkey importieren und zusätzlich den Widerruf für den alten Key nachziehen. Sonst schlagen Prüfungen älterer Downloads fehl.
  • Nutzer, die Firefox über bestimmte RPM-Pfade installieren: Hier kann es beim Update zu Fehlern kommen. Unter Umständen ist dann ein manueller Key-Tausch erforderlich, damit der Updateprozess die Signaturdaten korrekt verarbeiten kann.

Thunderbird hat dabei keine offiziell ausgewiesenen RPM-Pakete von Mozilla, wodurch diese spezielle RPM-Thematik für Thunderbird typischerweise nicht analog greift.

Der neue Subkey: Fingerprint und Gültigkeit

Als Ersatz hat Mozilla einen neuen Subkey veröffentlicht. Dessen Fingerprint lautet: 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3. Der Subkey ist bis zum 5. August 2028 gültig.

Der Widerruf betrifft einen früheren Subkey und damit die Verifizierbarkeit älterer Signaturen. Sobald der Widerruf in den lokalen GPG/OpenPGP-Keyring übernommen wurde, gilt: frühere Signaturen, die mit dem alten Key erstellt wurden, werden nicht mehr als zuverlässig eingestuft.

Was bedeutet OpenPGP-Widerruf praktisch?

OpenPGP erlaubt es, dass ein Key-Owner Gründe für den Widerruf mitliefert. Die zugrundeliegenden Regeln sind in RFC 4880 beschrieben: Entscheidend ist, warum ein Key widerrufen wurde.

Im Fall eines regulären Wechsels oder einer planmäßigen Ablösung können frühere Signaturen häufig weiterhin als gültig gelten, solange der Key nur „ersetzt“ wurde. Ein Widerruf wegen einer möglichen Kompromittierung ist dagegen deutlich strenger: Dann müssen alle Signaturen, die jemals mit dem betroffenen Key erzeugt wurden, als fragwürdig betrachtet werden.

Im veröffentlichten Widerrufsschein nennt der Reason-Code den Status „key material has been compromised“ (Code 2). Außerdem ist dokumentiert, dass der Widerruf am 6. August 2026 erstellt wurde. Mozilla hatte dabei sinngemäß festgehalten, dass sie dem Key nicht mehr vertrauen.

Warum alte Downloads plötzlich nicht mehr verifizieren

Ein zentraler Punkt: Mozilla weist darauf hin, dass ältere Archivsignaturen nach dem Import des Widerrufs nicht mehr geprüft werden können. Obwohl es sich um einen Subkey handelt, wirkt sich die Widerrufslogik auf die Vergangenheit aus.

Mozilla verwendet dabei eine Struktur, bei der ein primärer Schlüssel grundsätzlich bestehen bleibt, während der betroffene Subkey widerrufen wird. Die Schlüsselhierarchie sorgt dafür, dass der Primary Key weiterhin vorhanden bleibt – aber genau der Widerruf des Subkeys sorgt dafür, dass verifizierende Systeme ältere Signaturen nicht mehr als „vertrauenswürdig bestätigt“ einstufen.

Der Austausch kommt früher als geplant

Der neue Subkey wird laut Mozillas Zeitplan etwa rund seben Monate früher als üblich nach außen kommuniziert. Mozilla rotiert Subkeys demnach ungefähr im Zwei-Jahres-Rhythmus, um sich gegen unbekannte Leaks abzusichern – also auch ohne zu wissen, ob etwas tatsächlich passiert ist.

Der widerrufene Subkey war bereits im April 2025 angekündigt worden und hätte regulär noch bis März 2027 laufen sollen. Mit dem aktuellen Schritt zieht Mozilla die Sicherheitslinie offenbar strenger als der ursprüngliche Zeitplan vorsieht.

So läuft der Key-Tausch unter RPM-basierten Distributionen

Auf der RPM-Seite übernimmt je nach Distribution das Paketmanagement einen Teil der Arbeit automatisch. In manchen Fällen sorgt dnf dafür, dass Nutzer beim nächsten Update den aktualisierten Key nachladen und den zugehörigen Fingerprint bestätigen. In anderen Konfigurationen kann der Updateprozess jedoch scheitern, oder es werden widersprüchliche Repository-Keydaten gemeldet.

Ein wichtiger Aspekt: Der alte Key muss zuvor entfernt werden. Dabei kann ein „Import“-Befehl zwar erfolgreich wirken, aber der alte (veraltete) Key bleibt trotzdem im lokalen Keyring bestehen. Um das zu vermeiden, nennt Mozilla sinngemäß (bzw. lässt sich durch den beschriebenen Ablauf ableiten) eine Vorgehensweise, bei der alte Schlüssel zuerst entfernt und anschließend der neue Key importiert wird.

Für rpm/dnf-Setups wird dabei typischerweise mit Befehlen gearbeitet, die erst den alten gpg-pubkey entfernen und danach den neuen Signing-Key abrufen. Danach sollte ein Cache-Refresh erfolgen, damit die Paketquellen den neuen Schlüssel berücksichtigen.

Auf openSUSE ähnelt der Ablauf dem RPM-typischen Vorgehen: Nutzer können die entsprechenden rpm-Kommandos verwenden und anschließend das Paketquellen-Refresh per zypper anstoßen.

OpenPGP und RPM: Warum die Reihenfolge zählt

Die Reihenfolge ist hier entscheidend, weil die lokale Keyliste schnell „alte“ und „neue“ Einträge parallel enthalten kann. Wenn das System beim Verifizieren weiterhin auf den alten Key trifft, obwohl inzwischen ein neuer Subkey verfügbar ist, kann es zu scheinbar widersprüchlichen Fehlermeldungen kommen. Der Fix ist daher nicht nur „Key neu importieren“, sondern gezielt „den alten Key entfernen und den neuen korrekt eintragen“.

APT ist offenbar nicht betroffen

Mozilla äußert sich in diesem Zusammenhang nicht eindeutig dazu, welche Repositorys genau die Schlüsselverwaltung für alle Distributionen betrifft. Allerdings gilt: Für Debian/Ubuntu wird typischerweise ein anderer Key für APT-Quellen genutzt.

Mozilla macht außerdem klar, dass das aktuelle Ereignis .deb-Pakete nicht einschließt. Für Nutzer dieser Wege dürfte der Wechsel daher weniger wahrscheinlich direkte Installations- oder Updateprobleme auslösen.

Ein weiterer Sicherheitsvorfall kurz zuvor

Die Meldung kommt zeitlich nahe zu einem anderen Vorfall, bei dem Angreifer ein GitHub-Konto im Umfeld von keyv und cacheable npm packages übernommen haben soll. Dabei wurde nach Angaben in der Quelle ein Wurm veröffentlicht, der darauf abzielte, Repository-, Registry-, Cloud- und private-key-material aus Entwicklerumgebungen und CI-Pipelines zu sammeln.

Auch wenn das zwei unterschiedliche Geschichten sind, zeigt der Zeitraum: In der Praxis steigt der Druck auf Softwareteams, Signatur- und Schlüsselprozesse regelmäßig zu überprüfen und im Ernstfall schnell zu widerrufen.

Fazit: Signing-Key widerrufen – die meisten bleiben dennoch auf der sicheren Seite

Mozilla hat den Signing-Key für Firefox- und Thunderbird-Downloads unter Linux widerrufen, nachdem ein unverschlüsseltes Exemplar des Keys versehentlich in einem privaten Repo gelandet ist. Der Widerruf betrifft dabei insbesondere die Verifizierbarkeit älterer Signaturen: Sobald der Widerruf importiert wurde, werden frühere Downloads nicht mehr wie zuvor „durchgehend gültig“ bestätigt.

Wenn Sie Downloads normalerweise nur installieren und Updates über Ihr System beziehen, müssen Sie meist nichts tun. Wer jedoch Signaturen manuell prüft oder bestimmte RPM-Installationswege nutzt, sollte den Austausch des neuen Subkeys samt Widerruf zeitnah nachziehen. So vermeiden Sie, dass Verifizierungen überraschend fehlschlagen.

Quelle: https://thehackernews.com/2026/08/mozilla-revokes-firefox-and-thunderbird.html