Was tut ein Hersteller, wenn eine Sicherheitslücke bereits aktiv ausgenutzt wird, der reguläre Update-Prozess aber zu lange braucht? Laut Natalie Silvanovich von Googles Sicherheitsteam Project Zero äußern manche Hersteller genau diese Sorge: dass sie eine Lücke, die Nutzern gerade schadet, wegen der Grenzen ihrer Update-Systeme nicht schnell genug schließen können. In einem Beitrag auf dem Project-Zero-Blog trägt Silvanovich zusammen, mit welchen Notfallmechanismen große Anbieter einzelne Schwachstellen deutlich schneller beheben als über den üblichen Update-Zyklus. Das Team stützt sich dabei auf Gespräche mit Herstellern und auf eigene Sicherheitsanalysen.
Der Beitrag richtet sich an Hersteller, die solche Systeme aufbauen oder verbessern wollen, und soll sie dazu bringen, sich zu überlegen, wie sie eine dringende Lücke schließen würden, bevor sie eine gemeldet bekommen. Zur Einordnung: Project Zero gehört zu Google, und mehrere der genannten Beispiele, etwa Androids Intent Firewall, Google Play Protect, Android Pony Express und Chrome, stammen aus dem eigenen Konzern. Daneben nennt der Text Verfahren von Apple, Meta, Microsoft und Linux. Im Folgenden geht es um die einzelnen Verfahren, ihre Grenzen und die Frage, was davon in einen normalen Patch-Prozess passt.
Warum ein Patch sechs Schritte braucht, nicht einen
Zur Veranschaulichung taugt ein Vergleich, der nicht aus dem Bericht stammt: der Umbau eines bewohnten Hochhauses. Man reißt nicht einfach eine Wand heraus, weil ein Riss sichtbar geworden ist. Erst wird geprüft, wie schlimm der Riss ist und wer zuständig ist. Dann zeichnet jemand den neuen Grundriss, andere prüfen die Statik, die Feuerwehr prüft die Fluchtwege, am Ende wird gearbeitet, und danach kontrolliert noch jemand, dass das Haus wirklich steht. Eine ähnliche Abfolge von Stationen beschreibt Silvanovich für Software.
Der erste Schritt ist die Triage: Eine Meldung kommt an, wird geprüft, priorisiert und einer Person zugewiesen, die den Fehler behebt. Danach folgt die Entwicklung — Code schreiben, Review, Commit; hier entsteht der eigentliche Patch. Der dritte Schritt ist das Testen: nicht nur, ob die Lücke geschlossen ist, sondern ob die Software danach noch tut, was sie soll. Bei manchen Produkten kommt eine Partnerprüfung hinzu, etwa wenn Mobilfunkbetreiber ein Update abnehmen müssen. Dann die Auslieferung an die Nutzer, und in einigen Fällen ein weiterer Schritt wie ein Neustart, bevor die neue Version aktiv wird.
Die Liste ist vereinfacht. In der Praxis wiederholen sich Schritte, weil Tests fehlschlagen, oder es kommen weitere Beteiligte hinzu. Eine Sicherheitslücke schnell zu beheben ist kein einzelner Handgriff, sondern eine Kette — und die langsamste Station bestimmt das Tempo.
Warum Notfall-Patches nicht an der Entwicklung scheitern
Man könnte vermuten, dass im Notfall vor allem die Programmierarbeit zu lange dauert. Der Bericht zeichnet ein anderes Bild. Die Triage geht schnell, wenn klar ist, dass ein ernstes Problem vorliegt, und die Entwicklung lässt sich priorisieren. Verzögerungen entstehen hier nur selten, etwa bei besonders komplexen Lücken oder wenn ein Hersteller selbst nicht weiß, welche Bausteine in seinem Produkt stecken und wer sie intern betreut. Auch Verträge mit Partnern enthalten üblicherweise Ausnahmen für Notfälle.
Der Engpass liegt woanders: beim Testen und bei der Auslieferung. Jede Änderung an Software kann unerwartetes Verhalten erzeugen. Der schlimmste Fall ist ein Gerät, das nach dem Update nicht mehr funktioniert und auch keine weiteren Updates mehr empfangen kann. Es gab auch schon fehlerhafte Updates, die Nutzerdaten beschädigt oder gelöscht haben. Und jeder Funktionsverlust nach einem Sicherheitsupdate senkt die Bereitschaft, künftige Updates überhaupt zu installieren.
Wie teuer schlecht getestete Updates werden, hängt vom Produkt ab. Eine App, die nach einem Update nicht mehr startet, lässt sich über den Store neu installieren, die Daten liegen meist auf einem Server, der Schaden bleibt überschaubar. Ein unbrauchbar gewordenes Mobilgerät muss dagegen eingeschickt oder ersetzt werden, was den Hersteller echte Summen kostet. Updates werden deshalb häufig langsam ausgerollt, damit sich Probleme zeigen, bevor sie alle Nutzer erreichen. Schnelles und sauberes Patchen stehen in einem Spannungsverhältnis.
Dazu kommen technische Bremsen. Viele Systeme fragen in festen Intervallen nach Updates, wodurch die Verteilung an dieses Intervall gebunden ist. Push-Verfahren sind schneller, brauchen aber mehr Infrastruktur. Auch das Verhalten der Nutzer zählt: Wenn ein Patch eine Bestätigung oder einen Neustart verlangt, bleibt er liegen. Netzgeschwindigkeit und Datenkosten spielen ebenfalls eine Rolle. Chrome und Microsoft haben laut dem Bericht selbst beschrieben, wie schwierig Updates sind, die einen Neustart verlangen: Nutzer schieben ihn hinaus, und er kostet Zeit.
Feature-Flags: der Schalter für den Notfall
Feature-Flags sind Bedingungen im Quellcode, deren Ausgang von Werten abhängt, die ein Server liefert. Normalerweise nutzt man sie für A/B-Tests. Im Notfall lassen sich damit Funktionen abschalten, die eine Schwachstelle erreichbar machen. Ein bekanntes Beispiel ist die FaceTime-Lücke von 2019, bei der Apple die Gruppenfunktion vorübergehend per Flag deaktivierte. Mehrere Hersteller halten Video-Codecs, die ohne Nutzerinteraktion erreichbar sind, auf diese Weise schaltbar und können bei aktiver Ausnutzung auf einen anderen Codec zurückfallen.
Der Vorteil liegt nicht allein in der Geschwindigkeit. Wichtiger ist, dass beide Zustände eines Flags vorab getestet werden können. Ein dringendes Sicherheitsupdate muss damit keinen ungetesteten Code ausliefern. Zusätzlich ist die übertragene Datenmenge winzig, ein Flag-Wechsel erreicht Nutzer also deutlich schneller als ein vollständiges Update. Meta hat beschrieben, wie das Unternehmen zwei Versionen seiner WebRTC-Bibliothek in eine einzige Binärdatei kompiliert und per Flag umschaltet — fällt die neue Version auf, geht es schnell zurück zur alten.
Dasselbe Prinzip lässt sich mit zwei verschiedenen Bibliotheken bauen, die dieselbe Aufgabe erfüllen, etwa zwei H264-Implementierungen. Dann macht man eine Schwachstelle unerreichbar, ohne Funktion zu verlieren. Das erfordert zusätzliche Tests, aber solche, die im Vorfeld möglich sind. Denkbar ist auch eine zweite Variante, die teure Schutzmechanismen aktiviert, um viele mögliche Fehler vorsorglich zu blockieren.
Filter: Regeln vor der Schwachstelle
Filtering bedeutet, ungeprüfte Eingaben gegen einen dynamisch aktualisierbaren Regelsatz laufen zu lassen und genau die Eingaben zu blockieren, die eine Lücke erreichbar machen. Ein Beispiel ist Androids Intent Firewall, die bestimmte Nutzungen eines IPC-Mechanismus über eine aktualisierbare XML-Datei abschalten kann. Damit ließen sich zuletzt Lücken in Wallets Dritter blockieren.
Auf manchen Plattformen laufen ohnehin Endpoint-Schutzprogramme, etwa Microsoft Defender unter Windows oder Google Play Protect unter Android. Regeln, die konkrete Exploits blockieren, lassen sich dorthin sehr schnell ausliefern. Der Vorteil gegenüber Feature-Flags ist die Flexibilität: Für Flags muss man vorher wissen, welche Funktion man abschalten wollen würde. Ist diese Liste unvollständig, steht man im Ernstfall ohne Hebel da. Filter greifen dagegen auch bei Eingaben, an die vorher niemand gedacht hat.
Die Nachteile sind real. Filter müssen selbst geprüft werden, denn ein falsch geschriebener Ausdruck kann notwendige Systemfunktionen stören. Häufiges Filtern kostet Leistung, und die Tests neuer Regeln lassen sich nicht vorab erledigen, solange man die zu blockierende Lücke noch nicht kennt. Endpoint-Schutzprogramme verarbeiten außerdem sehr viel ungeprüfte Eingabe, oft mit hohen Rechten, und sind damit selbst nicht ohne Risiko. Wo sie ohnehin installiert sind, sieht Project Zero in ihnen trotzdem einen möglichen Weg für die Notfallbehebung.
Alternative Kanäle und Hotpatching: schnell, aber mit Nebenwirkungen
Android Pony Express ist ein Beispiel für einen zweiten Auslieferungsweg: Updates für einzelne besonders gefährdete Komponenten laufen schneller als ein komplettes Systemupdate, weil Hersteller sie nicht selbst integrieren müssen. Manche Anwendungen laden einzelne Bibliotheken außerhalb des regulären Update-Zyklus nach und binden sie zur Laufzeit ein. Das umgeht die Grenzen der Verteilung, hat aber eine harte Bedingung: Der Client muss prüfen können, dass die Bibliothek wirklich vom Hersteller stammt. Fehlt diese Prüfung, wird aus dem Notfallkanal eine kritische Schwachstelle.
Hotpatching geht weiter und schiebt kleinere Codeeinheiten direkt in den Speicher eines laufenden Prozesses. Linux unterstützt das mit Livepatch für Kernelfunktionen, Windows mit einem eigenen Verfahren für Sicherheitsupdates ohne Neustart. Der Nutzer merkt nichts, das Update ist sofort wirksam. Die Grenzen liegen in der Art der Änderung: Ändert ein Update die Definition einer Struktur, die mehrere Funktionen gemeinsam nutzen, wird das teilweise nicht unterstützt.
Auch hier gibt es Sicherheitsfragen. Wer Code in laufende Prozesse schreiben kann, braucht zeitweise Speicherseiten, die gleichzeitig beschreibbar und ausführbar sind — ein Zustand, den viele Schutzmechanismen eigentlich verhindern sollen. Noch etwas bleibt bestehen: Hotpatching löst das Auslieferungsproblem, nicht das Testproblem. Ein Patch, der ohne ausreichende Prüfung in den Speicher wandert, bleibt ein Patch ohne ausreichende Prüfung.
Was ein belastbarer Patch-Prozess vorher klären muss
Der Bericht endet nicht mit einem Werkzeug, sondern mit einer Begründung und einer Aufforderung. Die Begründung: Sprachmodelle erweitern nach Silvanovichs Einschätzung die Fähigkeiten von Angreifern wie Verteidigern, Schwachstellen zu finden und auszunutzen, und mehr Akteure können neuartige Angriffe schneller durchführen. Die Aufforderung: Hersteller sollen planen, wie sie ihre Nutzer im schlimmsten Fall, bei breiter aktiver Ausnutzung, schützen würden, und zwar bevor dieser Fall eintritt. Dafür müssen Notfallmechanismen weder schwergewichtig sein noch jeden denkbaren Fehler beheben können. Feature-Flags, Filter und alternative Update-Wege sollen kurzfristig die wahrscheinlichsten und schwersten Lücken entschärfen und die Geräte dabei halbwegs benutzbar halten. Als ersten Schritt empfiehlt der Beitrag eine Bestandsaufnahme der vorhandenen Update-Mechanismen und schnelle Abhilfe dort, wo Lücken bestehen.
Für die Praxis lässt sich daraus ableiten: Ein Unternehmen braucht mehr als einen Notausgang. Feature-Flags helfen bei Funktionen, die man vorab als Risiko erkannt hat, Filter auch bei Eingaben, an die niemand gedacht hat, alternative Kanäle und Hotpatching bei der Frage, wie ein Fix überhaupt ankommt. Diese Wege ergänzen sich, und keiner davon ersetzt die Tests. Wer nur den schnellsten Weg baut und den langsamsten nicht absichert, verschiebt das Problem.
Der Originaltitel des Beitrags lautet „How to fix a bug in a fix“. Unsere Lesart: Gemeint ist weniger ein zweiter, noch schnellerer Patch als die Vorbereitung darauf, die eigene Kette vom Fehlerbericht bis zur Aktivierung zu kennen, ihre langsamste Station zu identifizieren und für genau diese Station einen vorab geprüften Weg bereitzuhalten. Das Beheben einer Lücke und das Ausliefern der Korrektur sind zwei getrennte Aufgaben, und im Notfall entscheidet meist die zweite über das Tempo. Ob ein Hersteller vorbereitet ist, zeigt sich nicht an der Zahl seiner Patches, sondern daran, ob im Ernstfall ein Weg existiert, der schnell ist und trotzdem trägt.
Quelle: projectzero.google
