Anmerkung des Übersetzers: Zur besseren Lesbarkeit sind die Daten in Moskauer Zeit angegeben.
Kürzlich haben wir den Zeitpunkt des Ablaufs eines der Zertifikate, das zur Signierung von Erweiterungen verwendet wird, verpasst. Dies führte zur Deaktivierung von Erweiterungen für die Benutzer. Jetzt, da das Problem größtenteils behoben ist, möchte ich über die Einzelheiten des Vorfalls und die durchgeführten Arbeiten berichten.
Hintergrund: Erweiterungen und Signaturen
Installierte Add-ons müssen eine digitale Signatur, die die Benutzer vor schädlichen Add-ons schützt, und erfordert eine minimalen Überprüfung der Add-ons durch Mitarbeiter von Mozilla. Wir haben dieses Erfordernis 2015 eingeführt, da wir ernste Probleme mit schädlichen Add-ons hatten.
So funktioniert es: Jede Firefox-Kopie enthält ein „Wurzelzertifikat“. Der Schlüssel zu diesem „Wurzelzertifikat“ wird in einem Hardware-Sicherheitsmodul (HSM), das keinen Netzwerkzugang hat, gespeichert. Alle paar Jahre wird dieser Schlüssel verwendet, um ein neues „Intermediate-Zertifikat“ zu signieren, das zur Signierung von Erweiterungen genutzt wird. Wenn ein Entwickler eine Erweiterung sendet, erstellen wir ein temporäres „Endzertifikat“ und signieren es mit dem Intermediate-Zertifikat. Dann wird die Erweiterung mit dem Endzertifikat signiert. Schematically sieht das so aus.
Bitte beachten Sie: Jedes Zertifikat hat ein „Subjekt“ (wem das Zertifikat ausgestellt wurde) und einen „Aussteller“ (wer das Zertifikat ausgestellt hat). Im Falle eines Wurzelzertifikats ist das „Subjekt“ = „Aussteller“, aber bei anderen Zertifikaten ist der Aussteller das Subjekt des übergeordneten Zertifikats, das es signiert hat.
Ein wichtiger Punkt: Jede Erweiterung ist mit einem einzigartigen Endzertifikat signiert, aber fast immer sind diese Endzertifikate mit demselben Intermediate-Zertifikat signiert.
Hinweis des Autors: Eine Ausnahme bilden sehr alte Erweiterungen. Zu diesem Zeitpunkt wurden verschiedene Zwischenzertifikate verwendet.
Dieses Zwischenzertifikat verursachte Probleme: Jedes Zertifikat ist nur für einen bestimmten Zeitraum gültig. Vor oder nach diesem Zeitraum ist das Zertifikat ungültig, und der Browser wird Erweiterungen, die mit diesem Zertifikat signiert sind, nicht verwenden. Leider lief die Gültigkeit des Zwischenzertifikats am 4. Mai um 4 Uhr ab.
Die Auswirkungen traten nicht sofort auf. Firefox überprüft die Signaturen der installierten Erweiterungen nicht ständig, sondern etwa alle 24 Stunden, und der Zeitpunkt der Überprüfung ist individuell für jeden Benutzer. Daher hatten einige Nutzer sofort Probleme, während es bei anderen viel später auftrat. Wir erfuhren zum ersten Mal von dem Problem ungefähr zu dem Zeitpunkt, als das Zertifikat abgelaufen war, und begannen sofort mit der Suche nach einer Lösung.
Schaden minimieren
Sobald wir verstanden hatten, was passiert war, versuchten wir, eine Verschlechterung der Situation zu verhindern.
Zunächst wurde die Annahme und Unterzeichnung neuer Add-ons eingestellt. Es macht keinen Sinn, dafür ein abgelaufenes Zertifikat zu verwenden. Rückblickend würde ich sagen, dass es besser gewesen wäre, alles so zu belassen. Die Annahme von Add-ons wurde nun wieder aufgenommen.
Zweitens wurde umgehend ein Fix verteilt, der die tägliche Überprüfung von Signaturen verhinderte. So konnten wir die Benutzer retten, deren Browser in den letzten 24 Stunden noch keine Add-ons überprüft hatte. Dieser Fix wurde nun zurückgezogen, da er nicht mehr benötigt wird.
Parallele Arbeit
Theoretisch sieht die Lösung des Problems einfach aus: Wir erstellen ein neues, gültiges Zwischenzertifikat und signieren jedes Add-on erneut. Leider wird das nicht funktionieren:
- Wir können nicht schnell 15.000 Add-ons gleichzeitig neu signieren; das System ist nicht auf diese Last ausgelegt.
- Nachdem wir die Erweiterungen signiert haben, müssen die aktualisierten Versionen an die Benutzer ausgeliefert werden. Die meisten Erweiterungen werden von Mozilla-Servern installiert, daher wird Firefox in den nächsten 24 Stunden Updates finden. Einige Entwickler verteilen jedoch signierte Erweiterungen über alternative Kanäle, weshalb die Benutzer diese manuell aktualisieren müssten.
Stattdessen haben wir versucht, einen Fix zu entwickeln, der alle Benutzer erreicht, ohne (oder fast ohne) dass von ihnen Handlungen erforderlich sind.
Relativ schnell kamen wir auf zwei Hauptstrategien, die wir parallel verwendeten:
- Firefox zu aktualisieren, um die Gültigkeitsdauer des Zertifikats zu ändern. Dadurch würden bestehende Erweiterungen wieder magisch funktionieren, aber es wäre erforderlich, eine neue Version von Firefox zu erstellen und auszuliefern.
- Ein gültiges Zertifikat zu erstellen und Firefox irgendwie zu überzeugen, dieses anstelle des bestehenden zu akzeptieren, dessen Gültigkeit abgelaufen ist.
Wir entschieden uns zunächst für die erste Option, die recht vielversprechend erschien. Am Ende des Tages veröffentlichten wir auch die zweite Lösung (ein neues Zertifikat), über die wir im Folgenden sprechen werden.
Zertifikatserneuerung
Wie ich bereits erwähnt habe, war erforderlich:
- ein neues gültiges Zertifikat zu erstellen
- es remote in Firefox zu installieren
Um zu verstehen, warum dies funktionieren wird, betrachten wir den Verifikationsprozess des Add-ons genauer. Das Add-on selbst wird als eine Gruppe von Dateien bereitgestellt, einschließlich der Zertifikatskette, die zur Signatur verwendet wird. Dadurch kann das Add-on überprüft werden, wenn der Browser das Root-Zertifikat kennt, das während des Aufbaus in Firefox integriert wird. Wie wir jedoch bereits wissen, ist das Intermediärzertifikat abgelaufen, weshalb das Add-on nicht überprüft werden kann.
Wenn Firefox versucht, ein Add-On zu überprüfen, beschränkt er sich nicht auf die Verwendung von Zertifikaten, die im Add-On selbst enthalten sind. Stattdessen versucht der Browser, eine gültige Zertifikatkette zu erstellen, beginnend mit dem Endzertifikat und setzt fort, bis er zum Wurzelzertifikat gelangt. Auf der ersten Ebene beginnen wir mit dem Endzertifikat und suchen dann das Zertifikat, dessen Subjekt der Herausgeber des Endzertifikats ist (d.h. das Zwischenzertifikat). In der Regel wird dieses Zwischenzertifikat zusammen mit dem Add-On bereitgestellt, aber auch jedes Zertifikat aus dem Zertifikatsspeicher des Browsers kann diese Rolle übernehmen. Wenn wir in der Lage sind, remote ein neues gültiges Zertifikat zum Zertifikatsspeicher hinzuzufügen, wird Firefox versuchen, es zu verwenden. Die Situation vor und nach der Installation des neuen Zertifikats.
Nach der Installation des neuen Zertifikats wird Firefox bei der Überprüfung der Zertifikatskette zwei Optionen haben: das alte, ungültige Zertifikat (das nicht funktionieren wird) oder das neue gültige Zertifikat (das funktionieren wird). Wichtig ist, dass das neue Zertifikat den gleichen Subjektnamen und den gleichen öffentlichen Schlüssel wie das alte Zertifikat enthält, wodurch die Signatur im Endzertifikat gültig bleibt. Firefox ist intelligent genug, beide Optionen auszuprobieren, bis es eine funktionierende findet, sodass die Erweiterungen erneut als geprüft gelten. Bitte beachten Sie, dass dies die gleiche Logik ist, die wir zur Überprüfung von TLS-Zertifikaten verwenden.
Hinweis des Autors: Leser, die mit WebPKI vertraut sind, werden bemerken, dass auch die Cross-Zertifikate auf dieselbe Weise funktionieren.
Das Beste an dieser Lösung ist, dass es nicht erforderlich ist, bestehende Erweiterungen neu zu signieren. Sobald der Browser das neue Zertifikat erhält, werden alle Erweiterungen wieder funktionieren. Es bleibt jedoch die Herausforderung, das neue Zertifikat automatisch und aus der Ferne an die Benutzer zu bringen, sowie sicherzustellen, dass Firefox die deaktivierten Erweiterungen neu überprüft.
Normandy und das Forschungssystem
Ironischerweise wird dieses Problem durch ein spezielles Plugin namens „System“ gelöst. Um Forschungen durchzuführen, haben wir ein System mit dem Namen Normandy entwickelt, das die Studien an die Benutzer liefert. Diese Studien werden automatisch im Browser ausgeführt und haben erweiterten Zugriff auf die internen APIs von Firefox. Die Forschungen können neue Zertifikate in den Zertifikatspeicher hinzufügen.
Hinweis des Autors: Wir fügen kein Zertifikat mit besonderen Privilegien hinzu; es ist von einem Root-Zertifikat signiert, daher vertraut Firefox ihm. Wir fügen es einfach dem Pool der Zertifikate hinzu, die vom Browser verwendet werden können.
Das Ergebnis besteht also darin, eine Forschung zu erstellen:
- die einen von uns erstellten neuen Zertifikat für Benutzer festlegt
- die den Browser zwingt, deaktivierte Erweiterungen erneut zu überprüfen, damit sie wieder funktionieren
„Aber Moment“, werden Sie sagen, „Erweiterungen funktionieren doch nicht, wie kann ich ein systemweites Plugin starten?“. Lassen Sie es uns mit einem neuen Zertifikat signieren!
Lassen Sie uns alles zusammenfügen… warum dauert das so lange?
Also, der Plan: Ein neues Zertifikat zur Ablösung des alten ausstellen, ein systemtechnisches Update erstellen und dies den Nutzern über Normandy bereitstellen. Die Probleme, wie ich bereits erwähnt habe, begannen am 4. Mai um 4:00 Uhr, und bereits um 12:44 Uhr desselben Tages, weniger als 9 Stunden später, haben wir die Korrektur an Normandy gesendet. Es dauerte weitere 6 bis 12 Stunden, bis es alle Nutzer erreichte. Schon nicht schlecht, aber die Nutzer auf Twitter fragen, warum wir nicht schneller handeln konnten.
Zunächst einmal benötigte die Ausstellung des neuen Zwischenzertifikats Zeit. Wie bereits erwähnt, wird der Schlüssel des Root-Zertifikats sicher in einem Hardware-Sicherheitsmodul (HSM) aufbewahrt. Das ist aus sicherheitstechnischer Sicht gut, da der Root sehr selten verwendet wird und gut geschützt sein muss, aber es ist etwas umständlich, wenn man schnell ein neues Zertifikat signieren muss. Einer unserer Ingenieure musste ins HSM-Lager fahren. Dann gab es mehrere misslungene Versuche, das richtige Zertifikat auszustellen, und jeder Versuch kostete ein bis zwei Stunden für Tests.
Zweitens hat die Entwicklung des systemischen Add-ons einige Zeit in Anspruch genommen. Konzeptuell ist es sehr einfach, aber selbst einfache Programme erfordern Sorgfalt. Wir wollten sicherstellen, dass wir die Situation nicht noch schlimmer machen. Die Forschung muss getestet werden, bevor sie an die Benutzer gesendet wird. Zudem muss das Add-on signiert werden, aber unser System zur Signierung von Add-ons war deaktiviert, sodass wir einen Umweg suchen mussten.
Schließlich benötigten wir Zeit für die Bereitstellung, nachdem wir die Forschung zur Versendung vorbereitet hatten. Der Browser überprüft alle 6 Stunden auf Updates von Normandy. Da nicht alle Computer ständig eingeschaltet und mit dem Internet verbunden sind, benötigt das Update Zeit, um sich unter den Benutzern zu verbreiten.
Letzte Schritte
Die Forschung sollte das Problem für die meisten Benutzer beheben, ist aber nicht für alle verfügbar. Für einige Benutzer ist ein besonderer Ansatz erforderlich:
- Benutzer, die die Forschung oder Telemetrie deaktiviert haben
- Benutzer der Android-Version (Fennec), wo die Forschung überhaupt nicht unterstützt wird
- Benutzer von benutzerdefinierten Builds von Firefox ESR in Unternehmen, wo Telemetrie nicht aktiviert werden kann
- Benutzer, die über MitM-Proxy verbunden sind, da unser Add-On-Installationssystem Key-Pinning verwendet, das mit solchen Proxys nicht funktioniert.
- Benutzer veralteter Firefox-Versionen, die die erforderlichen Funktionen nicht unterstützen.
Leider können wir nichts für die letzte Benutzerkategorie tun – sie sollten dringend auf eine neue Version von Firefox aktualisieren, da die alten schwerwiegende, nicht geschlossene Sicherheitsanfälligkeiten aufweisen. Wir wissen, dass einige Nutzer an alten Firefox-Versionen festhalten, um alte Add-Ons auszuführen, aber viele dieser Add-Ons wurden bereits auf die neuen Browser-Versionen portiert. Für andere Benutzer haben wir einen Patch entwickelt, der ein neues Zertifikat installiert. Dieser wurde als Bugfix-Release veröffentlicht (Übersetzerhinweis: Firefox 66.0.5), sodass die Nutzer ihn wahrscheinlich bereits über den regulären Update-Kanal erhalten haben. Wenn Sie eine angepasste Version von Firefox ESR verwenden, wenden Sie sich bitte an Ihren Maintainer.
Wir verstehen, dass dies nicht ideal ist. In einigen Fällen haben Benutzer Daten von Add-Ons verloren (zum Beispiel die Daten des Add-Ons Multi-Account Containers).
Dieses Nebenwirkung ließ sich nicht vermeiden, aber wir sind der Meinung, dass wir kurzfristig die beste Lösung für die meisten Nutzer gewählt haben. Langfristig werden wir nach anderen, weiterentwickelten architektonischen Ansätzen suchen.
Lektionen
Zunächst hat unser Team großartige Arbeit geleistet, indem es weniger als 12 Stunden nach Entdeckung des Problems einen Fix erstellt und implementiert hat. Als jemand, der an den Sitzungen teilgenommen hat, kann ich sagen, dass die Leute in dieser schwierigen Situation sehr hart gearbeitet haben und nur sehr wenig Zeit verloren wurde.
Es ist offensichtlich, dass all dies überhaupt nicht hätte passieren sollen. Es ist klar notwendig, unsere Prozesse anzupassen, um die Wahrscheinlichkeit ähnlicher Vorfälle zu verringern und die Behebung der Folgen zu erleichtern.
Nächste Woche werden wir einen offiziellen Nachbericht und eine Liste der Änderungen veröffentlichen, die wir durchführen möchten. Bis dahin möchte ich meine Gedanken teilen. Erstens sollte es einen besseren Weg geben, um den Zustand von potenziellen Zeitbomben zu überwachen. Wir müssen sicherstellen, dass wir nicht in eine Situation geraten, in der eine von ihnen plötzlich auslöst. Wir arbeiten noch an den Details, aber mindestens ist es notwendig, eine Bestandsaufnahme all dieser Dinge durchzuführen.
Zweitens benötigen wir einen Mechanismus für die schnelle Bereitstellung von Updates an die Benutzer, selbst wenn – insbesondere wenn – alles andere nicht funktioniert. Es war großartig, dass wir ein System "Umfragen" verwenden konnten, aber es ist kein perfektes Werkzeug und hat einige unerwünschte Nebenwirkungen. Insbesondere wissen wir, dass viele Benutzer die automatische Aktualisierung aktiviert haben, aber lieber nicht an Umfragen teilnehmen würden (ich gestehe, ich habe sie auch deaktiviert!). Gleichzeitig benötigen wir eine Möglichkeit, Updates an die Benutzer zu senden, aber unabhängig von der internen technischen Umsetzung sollten die Benutzer in der Lage sein, sich für Updates (einschließlich dringender Korrekturen) anzumelden und alles andere abzulehnen. Darüber hinaus sollte der Aktualisierungskanal reaktionsschneller sein als jetzt. Selbst am 6. Mai gab es noch Benutzer, die weder die Korrektur noch die neue Version genutzt haben. An diesem Problem wurde bereits gearbeitet, aber die Ereignisse haben gezeigt, wie wichtig es ist.
Lassen Sie uns schließlich die Sicherheitsarchitektur der Erweiterungen überprüfen, um sicherzustellen, dass sie das erforderliche Sicherheitsniveau bietet, ohne das Risiko einzugehen, etwas zu beschädigen.
Nächste Woche werden wir die Ergebnisse einer gründlicheren Analyse des Vorfalls betrachten. Bis dahin stehe ich gerne per E-Mail zur Verfügung: ekr-blog@mozilla.com
Quelle: linux.org.ru
