HollowByte: Elf Bytes lassen OpenSSL-Server im Speicher erstarren : TLS-Fehler kann Speicher fragmentieren und Systeme bis zum Absturz belasten – Behebung erfolgte stillschweigend
Elf übertragene Bytes reichen aus, damit ungepatchte OpenSSL-Server bis zu 131 Kilobyte Speicher für Daten reservieren, die niemals eintreffen. Unter glibc kann dieser Speicher trotz geschlossener Verbindung dauerhaft im Prozess gebunden bleiben. Brisant ist auch der Umgang mit dem Fehler: OpenSSL veröffentlichte den Fix ohne CVE, Sicherheitswarnung oder eindeutigen Changelog-Hinweis.
Die von Okta als „HollowByte“ bezeichnete Schwachstelle steckt in der Verarbeitung des Transport Layer Security Handshake (TLS). Betroffen sind alle älteren Ausgaben der jeweiligen Versionszweige vor OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 und 3.0.21. Die korrigierten Versionen erschienen am 9. Juni 2026.
In üblichen Patch- und Schwachstellenprozessen fällt die Korrektur allerdings leicht durch das Raster. Es gibt weder eine CVE-Kennung noch eine offizielle Sicherheitswarnung oder einen Eintrag auf der OpenSSL-Seite zu bekannten Schwachstellen.
Der Server vertraut einer Längenangabe
Jede TLS-Handshake-Nachricht beginnt mit einem vier Byte langen Header. Drei Bytes geben an, wie groß der folgende Nachrichtenkörper sein soll. Ältere OpenSSL-Versionen vergrößern ihren Empfangspuffer unmittelbar auf den angekündigten Wert – noch bevor ein einziges Byte des eigentlichen Inhalts eingetroffen ist und bevor die Prüfungen des Handshake-Protokolls greifen.
Bei einem eingehenden ClientHello kann ein Angreifer damit die Reservierung von bis zu 131 Kilobyte auslösen. Anschließend wartet der zuständige Worker-Thread blockierend auf den angekündigten Rest der Nachricht. Dafür benötigt der Angreifer weder eine Anmeldung noch eine bestehende Sitzung oder einen ausgehandelten Schlüssel.
Der Angriff beginnt damit ähnlich wie klassische Verbindungserschöpfung nach dem Vorbild von Slowloris. Seine nachhaltige Wirkung entsteht jedoch erst durch das Zusammenspiel mit dem unter Linux verbreiteten Speicherverwalter glibc.
Freigegeben heißt nicht zurückgegeben
Bricht der Angreifer die Verbindung ab, gibt OpenSSL den reservierten Puffer zwar frei. glibc behält kleine und mittelgroße Speicherblöcke jedoch häufig im Heap des Prozesses, um sie später erneut zu verwenden, statt sie an den Kernel zurückzugeben.
HollowByte variiert bei jeder Verbindung die behauptete Nachrichtengröße. In den Tests von Okta verhinderte dies, dass der Allocator die freigegebenen Bereiche effizient wiederverwendete. Der Heap fragmentierte, während die Resident Set Size (RSS), also der tatsächlich im Arbeitsspeicher gehaltene Anteil des Prozesses, kontinuierlich anstieg. Die Speicherbelegung blieb auch nach dem Ende des Angriffs bestehen.
Bei Tests mit NGINX wurde ein Server mit einem Gigabyte Arbeitsspeicher durch den Out-of-Memory-Mechanismus (OOM) beendet, nachdem rund 547 Megabyte in Fragmenten gebunden waren. Auf einem System mit 16 Gigabyte ließen sich laut Okta etwa 25 Prozent des Speichers blockieren, ohne die zulässige Zahl gleichzeitiger Verbindungen zu überschreiten. Deshalb warnt das Red Team: „Übliche Schutzmaßnahmen zur Begrenzung von Verbindungen werden den Angriff nicht stoppen.“
Exploit-Code veröffentlichte Okta nicht. Auch ein öffentlich zugänglicher Proof of Concept war zum 18. Juli nicht bekannt.
OpenSSL wertet HollowByte nicht als Sicherheitslücke
OpenSSL behandelte die Korrektur lediglich als „Bug- oder Härtungsmaßnahme“. Diese Kategorie gehört nicht zu den vier offiziellen Sicherheitsstufen des Projekts, die von „Low“ bis „Critical“ reichen. Selbst als niedrig eingestufte Schwachstellen erhalten normalerweise eine CVE, einen Changelog-Eintrag und eine Meldung auf der Sicherheitsseite.
Die Begründung des zuständigen OpenSSL-Entwicklers: HollowByte sei kein Protokollfehler, sondern die Folge eines Servers, der im blockierenden Modus ohne geeignete Grenzwerte betrieben werde. Durch strengere Konfigurationen lasse sich das Risiko reduzieren.
Diese Bewertung entstand allerdings auf OpenBSD, das nicht glibc verwendet. Der Entwickler erklärte, mögliche Auswirkungen des Linux-Allocators bei der Einstufung „nicht berücksichtigt“ zu haben. Damit beruhen die Positionen auf unterschiedlichen Annahmen: OpenSSL betrachtet vor allem offene Verbindungen, Okta den Speicher, der nach deren Schließung fragmentiert im Prozess verbleibt.
Bemerkenswert ist zudem, dass OpenSSL das Problem dennoch durch eine Codeänderung behob. Der Puffer wächst nun schrittweise mit den tatsächlich eintreffenden Daten, statt die vom Kommunikationspartner behauptete Größe sofort vollständig zu reservieren.
Vergleichbare Fehler erhielten eine CVE
Die zurückhaltende Einstufung fällt auch deshalb auf, weil OpenSSL andere Speichererschöpfungsfehler offiziell als Sicherheitslücken führt. CVE-2025-66199 beispielsweise betrifft die Zertifikatskompression von TLS 1.3 und kann rund 22 Mebibyte Heap-Speicher pro Verbindung belegen. Dafür müssen jedoch mehrere Voraussetzungen erfüllt sein, darunter aktivierte Kompression und ausgehandelte Erweiterungen. HollowByte lässt sich dagegen ohne besondere Zusatzfunktionen oder vorherige Aushandlung auslösen.
Auch ein anderer, ebenfalls im Juni behobener Fehler, der im QUIC-PATH_CHALLENGE-Handler zu unbegrenztem Speicherverbrauch führen konnte, erhielt mit CVE-2026-34183 eine eigene Kennung und die Einstufung „Moderate“.
Downstream-Pakete schwer überprüfbar
Besonders problematisch ist die fehlende CVE für Linux-Distributionen, die Sicherheitskorrekturen zurückportieren. Red Hat behält beispielsweise häufig die ursprüngliche Versionsnummer eines Pakets bei. Normalerweise zeigen Security Advisories und maschinenlesbare Open Vulnerability and Assessment Language-Daten (OVAL) an, ob ein Backport enthalten ist. Ohne CVE fehlt dafür der zentrale Referenzpunkt.
Administratoren sollten deshalb prüfen, ob ihr Paket auf einer der Versionen vom 9. Juni basiert oder die folgenden Änderungen übernommen wurden:
- Pull Request 30792: Hauptzweig und OpenSSL 4.0
- Pull Request 30793: OpenSSL 3.6, 3.5 und 3.4
- Pull Request 30794: OpenSSL 3.0
Selbst kompilierte Installationen sollten auf OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 beziehungsweise 3.0.21 aktualisiert werden. Danach müssen alle Prozesse neu gestartet werden, die zuvor die verwundbare Bibliothek geladen hatten.
DTLS bleibt vorerst unverändert
Die Korrektur gilt ausschließlich für TLS. Datagram Transport Layer Security (DTLS) verwendet weiterhin den vom Kommunikationspartner gemeldeten Wert zur Dimensionierung des Puffers. Laut Patch-Autor Matt Caswell wäre eine saubere Anpassung dieses Pfades wesentlich invasiver gewesen, weshalb OpenSSL vorerst darauf verzichtete.
Ob auch die Extended-Support-Zweige 1.1.1 und 1.0.2 korrigiert wurden, blieb offen. Der zuständige Entwickler verwies lediglich auf das kostenpflichtige Supportportal. Damit zeigt HollowByte nicht nur ein technisches Problem bei der Speicherverwaltung, sondern auch eine Lücke in der Kommunikation: Wo CVE, Advisory und Changelog fehlen, können selbst eingespielte Updates nur schwer zuverlässig überprüft werden.