Zwei kritische Web-Bugs kamen nah genug zusammen, um das Internet fragil wirken zu lassen. TechCrunchs am Freitag veröffentlichter Rückblick darauf lohnt sich weniger wegen der Details der beiden Schwachstellen als wegen dessen, was das Paar über die Form des Webs verrät.
Die erste Lehre: Der Abhängigkeitsgraph des Webs ist ungleich verteilt. Eine kleine Zahl von Laufzeitumgebungen, Frameworks und Bibliotheken liegt unter einem enormen Anteil all dessen, was eine Seite ausliefert. PHP ist der klarste Fall — es trägt noch immer die Mehrheit der serverseitig gerenderten Seiten, von kleinen Firmenseiten auf Shared Hosting bis zu großen Installationen hinter einem CMS. Das ist keine Kritik an der Sprache, sondern eine Beschreibung des Schadensradius. Eine Schwachstelle in einer Komponente, die ein paar tausend spezialisierte Dienste nutzen, ist ein Sicherheitsvorfall. Eine Schwachstelle in einer Komponente, die die Mehrheit des Webs nutzt, ist ein Ereignis mit angehängter Uhr.
Die zweite Lehre betrifft den langen Schwanz. Die Offenlegung startet ein Rennen, aber nicht alle laufen mit. Große, gut besetzte Organisationen können ihre Exposition erfassen, einen gepatchten Build bauen, ihn gegen den eigenen Verkehr testen und ausrollen — manchmal binnen eines Tages. Der lange Schwanz kann das nicht. Die Website eines Restaurants liegt auf einem Shared Host mit einer abgekündigten Interpretersprache, weil ein Upgrade ein Plugin brechen würde, das seit sechs Jahren niemand angefasst hat. Eine Regionalbehörde hat keinen Verantwortlichen für den übernommenen Stack. Diese Hosts tauchen in keiner Patch-Statistik auf, die eine Behebung abgeschlossen aussehen lässt. Sie sind der Grund, warum eine Schwachstelle Wochen nach der Warnung noch Vorfälle produziert.
Ein Detail der Berichterstattung dieser Woche ist für Babelwire-Leser besonders erwähnenswert: Nur wenige Tage zuvor hatte eine kritische PHP-Schwachstelle die Patch-Debatte bestimmt, während Administratoren das Risiko eines Notfall-Upgrades gegen das Risiko ungetesteter Deployments abwogen. Das ist das kennzeichnende Dilemma konzentrierter Infrastruktur — der sichere Schritt und der dringende Schritt sind nicht derselbe, und die Entscheidung fällt, bevor die Beweislage vollständig ist.
Was sich strukturell verändert hat und was ein Paar von Bugs nach mehr als Zufall aussehen lässt, ist das Tempo auf der Gegenseite. Automatisierte Analyse und zunehmend leistungsfähige Werkzeuge pressen die Lücke zwischen Offenlegung und Ausnutzung zusammen. Wo Verteidiger früher Tage hatten, in denen ein funktionierender Exploit theoretisch war, haben sie heute oft Stunden, in denen er es nicht ist. Eine Organisation, deren Deployment-Pipeline ein Änderungsfenster größer als die Entwicklungszeit des Exploits verlangt, ist funktional ungepatcht, egal was ihr Scanner meldet.
Die praktischen Antworten sind unspektakulär und weitgehend bekannt — weshalb sie unterbleiben. Inventar: Man kann nicht patchen, was man nicht erfasst hat, und weh tun die Komponenten, die niemand gelistet hat. Virtuelles Patchen: Eine WAF-Regel gegen das Exploit-Muster kauft die Zeit, die ein Rebuild nicht kaufen kann. Gestaffelter Rollout mit Rückweg: Die Fähigkeit, sicher zurückzurollen, ermöglicht überhaupt erst das schnelle Deployment. Und ein Verantwortlicher für jeden erreichbaren Dienst, auch für die, die älter sind als das aktuelle Team.
Nichts davon ist ein Grund zur Panik über die Fundamente des Webs. Es ist ein Grund, Konzentration als Designvariable zu behandeln statt als Hintergrundtatsache. Das Bug-Paar wird gepatcht, die Warnungen werden aus den Feeds altern, und die zugrunde liegende Verteilung — eine Handvoll Komponenten, die den meisten Verkehr trägt, und ein langer Schwanz, der spät patcht — wird beim nächsten Mal exakt dieselbe sein.
Zu beobachten ist: ob eine der beiden Schwachstellen bestätigte massenhafte Ausnutzung statt theoretischer Exposition erzeugt; ob große Shared Hoster und CMS-Anbieter verwaltete Updates ausliefern, statt sich auf Kunden zu verlassen; und ob diese Woche zu einer dauerhaften Änderung dabei führt, wie Organisationen die Laufzeitumgebungen erfassen, die sie nicht selbst gewählt haben.
