Elf Byte und ein wartender Thread

Jemand aus dem Red Team von Okta schickte einem Server 11 Byte und sah zu, wie dieser 131 Kilobyte beiseitelegte. Der Kniff steckt im Beginn einer TLS-Verbindung. Die ersten vier Byte einer Handshake-Nachricht geben an, wie lang die Nachricht wird, und ältere OpenSSL-Versionen glaubten dieser Angabe und reservierten den Puffer, bevor der Rest eintraf oder irgendeine Prüfung lief. Der Rest der Nachricht kam nie an. Der Speicher blieb reserviert, und ein Arbeitsthread wartete auf Daten, die nicht mehr kommen würden.

Wiederholt man das, wird es deutlich. Auf einem Server mit einem Gigabyte ließ das Team 547 Megabyte in unbrauchbaren Fragmenten gefrieren. Auf einer Maschine mit sechzehn Gigabyte blockierten sie ein Viertel des Gesamtspeichers. Auf Systemen mit dem glibc-Allokator kommt der Speicher auch nach dem Verbindungsabbruch nicht sauber zurück, weil die freigegebenen Fragmente nicht wiederverwendet werden können. Es brauchte keine Zugangsdaten, es kam keine Sitzung zustande, und nichts an dem Austausch sah nach einem Angriff aus.

Der Teil, der eine Führungskraft mehr beunruhigen sollte als einen Entwickler

OpenSSL hat es behoben. Die Versionen 4.0.1, 3.6.3, 3.5.7, 3.4.6 und 3.0.21 erschienen alle am 9. Juni 2026 mit dem korrigierten Verhalten und reservieren Speicher erst, wenn Daten tatsächlich eintreffen. Drei Pull Requests mit den Nummern 30792, 30793 und 30794 trugen die Änderung. Danach wurde über fünf Wochen lang nichts dazu gesagt. Die öffentliche Offenlegung erreichte die Mailingliste oss-security am 18. Juli, 39 Tage nachdem die Korrektur bereits im Umlauf war.

Das Sicherheitsteam traf eine bewusste Entscheidung. OpenSSL führt ein vierstufiges Schweregradsystem von Kritisch bis Niedrig und befand, dass dieser Fall in keine der Stufen gehört. Der Pull Request hält ausdrücklich fest, dass das Team die Meldung als reine "Fehler- oder Härtungskorrektur" behandeln wollte. Es gibt daher keine CVE-Kennung, kein Sicherheitsadvisory und keinen Eintrag in den Changelogs der betroffenen Releases. Jede dieser Auslassungen ist eine Entscheidung, und jede entfernte ein Signal, auf dessen Erkennung irgendein Prozess gebaut war.

Der disziplinierte Prozess verlor gegen den undisziplinierten

Nehmen wir zwei Unternehmen. Das erste patcht OpenSSL in festem Monatsrhythmus, unabhängig davon, was das Release enthält. Es ist der Ansatz, dem eine reife Sicherheitsfunktion gern entwächst, weil er Wartungsfenster für belanglose Releases verbraucht. Dieses Unternehmen ist seit Juni geschützt und ahnt nicht, dass es je gefährdet war.

Das zweite priorisiert nach Schweregrad. Es liest die Advisories, bewertet die CVEs, zieht Kritisch und Hoch vor und stellt den Rest mit dokumentierter Begründung zurück. Das ist der Ansatz, der ein Audit besteht, einen Versicherer zufriedenstellt und eine Frage im Aufsichtsrat übersteht. Dieses Unternehmen sah sich das Juni-Release von OpenSSL an, fand keinen Sicherheitsinhalt und entschied völlig richtig, dafür kein Wartungsfenster zu opfern. Es ist weiterhin angreifbar, und sein Prozess funktionierte exakt wie entworfen.

Die unbequeme Schlussfolgerung lautet: Wer nach Schweregrad patcht, lagert seine Risikoentscheidungen an denjenigen aus, der den Schweregrad vergibt. Das ist kein Vorwurf an OpenSSL, ein stark von Freiwilligen getragenes Projekt, das vertretbare Entscheidungen über eine vierstufige Skala trifft, die es niemandem schuldet. Es ist eine Feststellung darüber, wo das Urteil tatsächlich liegt. Wenn Ihr Prozess nur eskaliert, was bereits als gefährlich etikettiert ankommt, dann ist Ihr Bedrohungsmodell in Wahrheit die Etikettierungspraxis Ihrer Lieferanten.

Zwei Dinge gelten heute weiterhin

Der DTLS-Pfad blieb unangetastet. Eine saubere Korrektur galt vorerst als zu tiefgreifend, deshalb bemisst dieser Code seinen Puffer weiterhin nach der Längenangabe der Gegenstelle. Wer irgendwo DTLS terminiert, und das tun viele VPN-Konzentratoren, WebRTC-Medienserver und industrielle IoT-Gateways, dessen Risiko wird von nichts hier Beschriebenem behoben. Ein verborgenes Geheimnis ist es allerdings auch nicht. Es steht offen in der Offenlegung, was für sich genommen eine Warnung ist.

Das Zweite betrifft den Zeitverlauf. Normalerweise erscheinen Offenlegung und Patch gemeinsam, und Verteidiger und Angreifer starten an derselben Linie. Hier lag der korrigierte Code 39 Tage lang in öffentlichen Commits, bevor jemand erklärte, was er korrigierte. Einen Commit-Diff zu lesen ist keine exotische Fähigkeit. Über einen Monat lang waren die Leute im Vorteil, die Code lesen, gegenüber denen, die Bulletins lesen, und die zweite Gruppe wusste nicht, dass ein Rennen begonnen hatte.

Die Frage für Ihre nächste Patch-Besprechung

Bauen Sie Ihr Schwachstellenprogramm nicht wegen eines Speicherfehlers um. Ergänzen Sie aber die ohnehin stattfindende Besprechung um eine wiederkehrende Frage: Was haben wir dieses Quartal nicht gepatcht, weil es ohne Schweregrad ankam? Nicht, was wir als Niedrig zurückgestellt haben. Sondern was nie in die Warteschlange kam, weil nichts es etikettierte. Diese Liste gibt es in jeder Organisation, und fast niemand sieht sie sich an.

Gleichen Sie danach Ihre OpenSSL-Versionen mit den Releases vom 9. Juni ab, was Minuten dauert, und halten Sie fest, ob Sie durch Richtlinie oder durch Glück geschützt sind. Der Unterschied zwischen diesen beiden Antworten ist der ganze Punkt. Eine Maßnahme, die zufällig schützt, ist keine Maßnahme, und beim nächsten Mal, wenn der Zufall ausbleibt, erfahren Sie das auf teure Weise.

Weiterlesen: Der Fix war 81 Tage vor der Warnung öffentlich  |  Eine Anfrage konnte Ihre WordPress-Seite kapern