HollowByte: OpenSSL-Sicherheitslücke lähmt Server mit 11 Bytes

Elf Bytes genügen, um einen Server ins Schwitzen zu bringen. Die OpenSSL Sicherheitslücke mit dem Namen HollowByte erlaubt es nicht authentifizierten Angreifern, den Speicher eines TLS-Servers dauerhaft aufzublähen – mit einem lächerlich kleinen Datenvolumen. Das OpenSSL-Team hat den Fehler bereits behoben, allerdings still und ohne CVE-Nummer. Genau das macht den Fall interessant.

So funktioniert die OpenSSL Sicherheitslücke HollowByte

Beschrieben hat den Fehler das Red Team von Okta. Jede Nachricht im TLS-Handshake beginnt mit einem vier Byte großen Header; darin steht in drei Bytes, wie groß die folgenden Handshake-Daten sein sollen. Verwundbare OpenSSL-Versionen reservieren diese angekündigte Größe, bevor die Nutzdaten überhaupt eingetroffen und geprüft sind.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Ein Angreifer öffnet also eine TLS-Verbindung, schickt elf Bytes und behauptet darin, es folge eine sehr viel größere Nachricht. Der Server reserviert den Speicher und wartet. „Der Worker-Thread blockiert dann und wartet unbegrenzt auf Daten, die nie ankommen“, schreibt Okta. Wiederholt man das über viele Verbindungen, bindet man mit minimalem Traffic erheblichen Speicher.

Warum der Speicher nicht zurückkommt

Der eigentliche Kniff liegt eine Ebene tiefer. OpenSSL gibt die Puffer zwar frei, wenn die Verbindung abbricht. Die GNU C Library (glibc) reicht kleine bis mittlere Allokationen aber nicht sofort ans Betriebssystem zurück, sondern behält sie zur Wiederverwendung. Wer nun Wellen von Verbindungen mit zufällig gewählten Größenangaben fährt, verhindert genau diese Wiederverwendung. Der Heap fragmentiert, die Resident Set Size steigt kontinuierlich – und bleibt oben, auch nachdem der Angreifer längst weg ist. Vollständig zurückholen lässt sich der Speicher nur durch einen Neustart des Prozesses.

Wie groß ist der Schaden wirklich?

Okta hat den Angriff gegen NGINX getestet. Eine einzelne gefälschte Größenangabe reserviert bis zu 131 KB Speicher. In einer Testumgebung mit 1 GB RAM war der NGINX-Server nach 547 MB eingefrorenem Speicher tot – Out-of-Memory-Kill. Auf einem Server mit 16 GB RAM band der Angriff 25 Prozent des gesamten Arbeitsspeichers, ohne dabei die übliche Obergrenze für gleichzeitige Verbindungen zu reißen. Klassische Verbindungslimits greifen hier also nicht. (BleepingComputer beschreibt denselben Punkt als „Angriffsbandbreite unter den Alarmschwellen“; Okta selbst spricht ausdrücklich vom Verbindungslimit.) Das ist der unangenehme Teil: Der Angriff sieht im Monitoring nicht nach Angriff aus.

Ehrliche Einordnung trotzdem: Ein Denial of Service ist weniger gravierend als Datenabfluss oder Codeausführung. Es gibt keinen Diebstahl, keine Rechteausweitung. Was bleibt, ist Betriebsstörung – und die kann bei einer Bibliothek, die praktisch überall steckt, breit wirken. OpenSSL ist in NGINX und Apache eingebaut, in Laufzeitumgebungen wie Node.js, Python, Ruby und PHP, in Datenbanken wie MySQL und PostgreSQL, und es ist auf den meisten Linux-Distributionen vorinstalliert.

Die Patches – und die Debatte um den stillen Fix

Behoben ist HollowByte in OpenSSL 4.0.1, zurückportiert wurde der Fix auf die Versionen 3.6.3, 3.5.7, 3.4.6 und 3.0.21. Diese Versionen vergrößern den Puffer erst, wenn die Daten tatsächlich eintreffen, und ignorieren die Angabe im Header.

Der Fix ging als „Hardening“ durch: keine CVE-Nummer, kein Security-Advisory. Im Commit steht zwar der Hinweis, dass die Änderung auf eine Meldung des Okta Red Team an das openssl-security-Team zurückgeht – eingestuft wurde sie aber ausdrücklich als „bug or hardening only fix“. Wer nur sicherheitsmarkierte Changesets nachzieht oder seine Patch-Prioritäten an CVE-Nummern hängt, übersieht den Fix deshalb. Okta selbst empfiehlt trotz der Einstufung, die OpenSSL-Pakete der eigenen Distribution umgehend zu aktualisieren. Dem schließe ich mich an – die Aktualisierung kostet nichts und ist ohnehin überfällig, wenn Ihre Systeme noch auf älteren Ständen laufen.

Konkrete Schritte

• openssl version auf allen TLS-terminierenden Systemen prüfen, inklusive Reverse Proxies und Datenbanken.
• Distributionspakete aktualisieren – auf einer der genannten Zielversionen landen.
• Dienste nach dem Update neu starten; verlinkte Prozesse behalten sonst die alte Bibliothek im Speicher.
• RSS-Verläufe der TLS-Dienste im Monitoring beobachten, nicht nur Bandbreite und Verbindungszahl.

Besonders relevant ist das für alle, die selbst hosten – Heimserver, NAS-Systeme, kleine VPS. Wenn Sie in dieser Richtung unterwegs sind, lohnt ein Blick in meinen Ratgeber zu NAS und Heimserver für Selfhosting. Und wer noch auf einer abgelaufenen Distribution sitzt, holt das Thema besser gleich mit ab: siehe Ubuntu 25.10 ohne Updates.

Quellen

• Okta Security Research: OpenSSL HollowByte – a DoS hiding in 11 bytes
• BleepingComputer: HollowByte DDoS flaw bloats OpenSSL server memory with 11-byte payload (17.07.2026)
• oss-security: OpenSSL „HollowByte“ DoS via attacker-controlled memory allocation size in glibc (18.07.2026)
• SecurityWeek: OpenSSL Silently Fixes „HollowByte“ DoS Vulnerability