Was Apple am 27. Juli veröffentlichte

Apples Sicherheitsseiten füllten sich am 27. Juli in einem einzigen Block. macOS Tahoe 26.6 erschien als Build 25G72 mit 155 eindeutigen CVE-Kennungen, daneben Safari 26.6. iOS 26.6 und iPadOS 26.6 führten 78 einzelne Schwachstelleneinträge zu 87 eindeutigen CVEs auf. Die Aktualisierungen für watchOS, tvOS und visionOS 26.6 kamen auf weitere 194, nachdem die Überschneidungen zwischen den Plattformen entfernt waren.

Die genannten Komponenten lesen sich wie eine Bestandsaufnahme des gesamten Systems und nicht wie eine einzelne schwache Ecke. Auf dem Telefon betreffen die Korrekturen den Kernel, WebKit, WLAN, Siri, den App Store, MediaRemote, ImageIO, SceneKit, libc, CloudAttestation, Game Center, Bedienungshilfen und Kontakte. Auf dem Mac sind die Beschreibungen deutlicher: Fehler, durch die eine Anwendung Root-Rechte erlangen, ihre Sandbox verlassen, Gatekeeper umgehen, an den Datenschutzeinstellungen vorbeigreifen oder geschützte Daten erreichen konnte.

Apple erklärt nicht, dass eine davon vor Auslieferung der Updates ausgenutzt wurde, und kein Medium hat Gegenteiliges belegt. Das Zählen fällt merkwürdig schwer: Fachpublikationen kommen anhand desselben Apple-Dokuments auf Werte zwischen rund 130 und 155, je nachdem, ob sie Einträge oder Kennungen zählen. Diese Spanne ist eine Kleinigkeit, aber sie zeigt, dass die Aufstellung für Menschen geschrieben ist und nicht für ein Werkzeug, das sie auswertet.

Sieben Anläufe sind der eigentliche Befund

Das Entscheidende steckt nicht in der CVE-Zahl. macOS Sequoia 15.7.8 und macOS Sonoma 14.8.8 erschienen am selben Tag, und sie erreichten die Freigabe erst, nachdem Apple sieben Release Candidates herausgegeben hatte. Ein fünfter Kandidat am 13. Juli war ungewöhnlich genug, um für sich genommen als selten berichtet zu werden. Zwei weitere folgten.

Das ist ein technisches Signal, keine Randnotiz. Ein Release Candidate ist der Stand, den ein Hersteller für fertig hält. Sieben davon auszugeben bedeutet, dass Apple die Rückportierung wiederholt für abgeschlossen hielt und wiederholt feststellte, dass sie es nicht war. Der aktuelle Zweig, Tahoe, brauchte dieses Hin und Her nicht: Er wurde einmal gegen den Code geschrieben, für den die Korrekturen gedacht waren.

Zusammen beheben Sequoia 15.7.8 und Sonoma 14.8.8 mehr als 138 verschiedene Schwachstellen. Der Umfang ist mit Tahoe vergleichbar. Anders ist die Mühe, ihn dorthin zu bringen, und Apples Versionshinweise für die beiden älteren Zweige sagen dazu fast nichts. Sie bieten nur, dass es sich um wichtige Sicherheitskorrekturen handelt, empfohlen für alle Nutzer, die noch darauf arbeiten.

Das Stabilitätsargument läuft rückwärts

Die meisten Flotten, die eine Version zurückliegen, tun das bewusst. Die Begründung ist vertraut und meist vernünftig: andere die Regressionen finden lassen, den Bestand auf einem Build halten, der lange genug in der Welt ist, um langweilig zu sein, und dann aktualisieren, wenn das Geschäft eine ruhige Woche hat. Auf Funktionen angewandt trägt diese Logik.

Auf Sicherheitsupdates angewandt kehrt der 27. Juli sie um. Der ältere Zweig ist nicht der gesetztere. Er ist derjenige, für den sieben Anläufe nötig waren, denn eine Rückportierung ist nicht dieselbe Arbeit wie eine Korrektur: Der Fehler wird im aktuellen Code gefunden und behoben und dann rückwärts in eine Codebasis getragen, die sich seither weiterbewegt hat. Jede Version Abstand zwischen Ihrem Bestand und Apples vorderster Linie ist technische Entfernung, die jemand unter Zeitdruck überbrücken muss, und in diesem Monat brauchte es dafür sieben Versuche.

Der Punkt zweiter Ordnung betrifft Nachweise, nicht Risikobereitschaft. NIS2 verlangt von betroffenen Organisationen, Schwachstellen als dokumentierten Prozess zu behandeln und nicht als Bauchgefühl, und die Frage einer Prüfung lautet selten, ob Sie gepatcht haben. Sie lautet, wann Sie es wussten, was Sie entschieden haben und warum. "Wir bleiben aus Stabilitätsgründen eine Version zurück" ist nur so lange eine tragfähige Antwort, bis die Aufzeichnungen zeigen, dass der ältere Zweig Korrekturen langsamer und brüchiger erhält. In Deutschland liest das BSI diese Aufzeichnungen, und für Organisationen mit britischem Geschäft landet dieselbe Frage beim NCSC.

Die Reihenfolge für diese Woche

Beginnen Sie mit den Geräten, die bereits exponiert sind, nicht mit den am leichtesten erreichbaren. Alles, was Safari oder WebKit gegen nicht vertrauenswürdige Seiten einsetzt, jeder Mac, auf dem ein normaler Nutzer plausibel dazu gebracht werden könnte, eine präparierte Datei zu öffnen, und jedes Gerät außerhalb des Büronetzes gehört in die erste Welle. Die Umgehungen von Gatekeeper und Datenschutzeinstellungen wiegen am schwersten bei Notebooks, die das Gebäude verlassen.

Gehen Sie danach ehrlich mit dem älteren Bestand um. Wenn eine Gruppe Macs auf Sonoma oder Sequoia läuft, weil die Hardware Tahoe nicht trägt, ist das eine Tatsache, die man einplant und irgendwann budgetiert, keine Haltung, die man verteidigt. Laufen sie aus freier Entscheidung auf einer älteren Version, ist dies der Monat, in dem zu fragen ist, ob diese Entscheidung noch das einbringt, wofür sie gedacht war.

Eine Sache zum Festhalten. Notieren Sie das Datum der Veröffentlichung der Hinweise und das Datum, an dem jede Gerätegruppe aktualisiert wurde, denn der Abstand zwischen diesen beiden Zahlen ist das Einzige daran, was eine Prüfung später nachvollziehen kann, und das Einzige, was Sie steuern.

Weiterlesen: Der nginx-Patch ist da, der Exploit kommt im August  |  Zwei Cursor-Lücken mit CVSS 9.8 liefern Angreifern den Rechner des Entwicklers aus