HollowByte: Wie ein 11-Byte-Paket OpenSSL-Server-Speicher aufbläht — kein CVE, aber gepatcht in 4.0.1/3.6.3/3.5.7/3.4.6/3.0.21

TL;DR — 90 Sekunden

Betroffen?

OpenSSL-Versionen vor 4.0.1, 3.6.3, 3.5.7, 3.4.6 bzw. 3.0.21 (je nach genutztem Branch), die TLS-Verbindungen serverseitig terminieren.

Risiko?

Kein CVE, kein CVSS-Score — von OpenSSL als Hardening-Fix eingestuft, nicht als klassische Sicherheitslücke. Denial-of-Service durch Speicher-Erschöpfung: Ein 11-Byte-Paket mit überhöhter Längenangabe lässt den Server Speicher für nie ankommende Daten reservieren; durch glibc-Allokator-Verhalten bleibt dieser Speicher auch nach Verbindungsende aufgebläht.

Sofortmaßnahme?

Auf die gepatchte Version aktualisieren (4.0.1 / 3.6.3 / 3.5.7 / 3.4.6 / 3.0.21) und betroffene Worker-Prozesse neu starten, um bereits aufgeblähten Speicher zurückzugewinnen — der Patch allein reicht ohne Neustart nicht.

Empfehlung?

Bei öffentlich erreichbaren TLS-Terminierungspunkten (Reverse-Proxys, Load-Balancer, direkte OpenSSL-Nutzung) zeitnah patchen — besonders bei kleinen, ressourcenbeschränkten Instanzen, die laut Testberichten leicht erschöpfbar sind.

Kritikalität?

medium — kein Datenabfluss und keine Code-Ausführung, aber eine nachweislich wirksame, ressourcenarm durchführbare DoS-Technik gegen weitverbreitete TLS-Infrastruktur.

Was ist das Problem?

Während eines TLS-Handshakes kündigt jede Nachricht in ihrem Header an, wie viele Bytes an Nutzdaten folgen. Verwundbare OpenSSL-Versionen reservieren den dafür nötigen Speicher bereits beim Lesen dieser Ankündigung — nicht erst, wenn die Daten tatsächlich eingetroffen und in ihrer Größe verifiziert sind. Ein Angreifer nutzt genau diese Reihenfolge aus: Ein Paket von nur 11 Byte Gesamtgröße genügt, um im Header eine erheblich größere Nachricht anzukündigen. Der Server allokiert den entsprechenden Speicherblock und wartet dann — unter Umständen sehr lange — auf Daten, die nie gesendet werden.

Der eigentliche Vervielfältigungseffekt entsteht durch das Zusammenspiel mit glibcs Speicherverwaltung: glibc gibt kleine bis mittelgroße Allokationen nach ihrer Freigabe nicht sofort an das Betriebssystem zurück, sondern hält sie zur möglichen Wiederverwendung vor. Ein Angreifer, der über mehrere Wellen hinweg Verbindungen mit zufällig variierten, jeweils unterschiedlich großen angekündigten Nachrichtenlängen öffnet, verhindert gezielt, dass diese Speicherblöcke wiederverwendet werden können — die Folge ist fortschreitende Heap-Fragmentierung. Diese Fragmentierung überdauert das Ende der einzelnen Verbindungen; der Prozess bleibt aufgebläht, bis er neu gestartet wird.

OpenSSL behandelt HollowByte als Hardening-Maßnahme statt als Sicherheitslücke im engeren Sinn, vermutlich weil kein Speicherfehler im klassischen Sinn (Buffer Overflow, Use-after-Free) vorliegt, sondern ein Ressourcen-Management-Problem. Der Fix ändert das Allokationsverhalten: Der Puffer wächst erst mit tatsächlich eingehenden Daten, nicht mit der Header-Ankündigung.

Wer ist betroffen?

Die eigene OpenSSL-Version lässt sich schnell prüfen: openssl version auf dem Host bzw. openssl version innerhalb des jeweiligen Container-Images.

Auswirkungen

HollowByte führt zu keinem Datenabfluss und keiner Code-Ausführung — der Impact ist reine Verfügbarkeit. Laut den ausgewerteten Berichten zeigte Oktas Red-Team-Testing gegen NGINX, dass ressourcenarme Umgebungen leicht bis zur Erschöpfung getrieben werden können, während größere Server bis zu 25 % ihres Speichers verlieren können, ohne dass übliche Alarmschwellen für Speicherauslastung überschritten werden — ein Muster, das klassische Monitoring-Schwellenwerte gezielt unterläuft.

Besonders unangenehm im Betrieb: Der aufgeblähte Speicher bleibt bestehen, auch wenn der Angreifer längst aufgehört hat und alle Verbindungen getrennt sind — ein einfacher Verbindungsabbruch oder eine Rate-Limiting-Regel gegen neue Verbindungen macht bereits entstandenen Schaden nicht rückgängig. Ohne Prozess-Neustart bleibt der Speicherverbrauch dauerhaft erhöht, was wiederkehrende Ausfälle unter Last, erhöhte Swap-Nutzung oder OOM-Kills durch den Kernel begünstigt.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Sie öffentlich erreichbare, ressourcenbeschränkte TLS-Terminierungspunkte (kleine VMs, Edge-Instanzen, Ingress-Controller mit engen Speicherlimits) auf ungepatchtem OpenSSL betreiben.
• Mit Priorität prüfen, wenn … Sie größere Server/Cluster betreiben, die TLS terminieren — der Effekt ist hier langsamer, aber laut Testberichten bis zu 25 % Speicherverlust ohne Alarm möglich.
• Im nächsten regulären Fenster, wenn … Ihre Systeme TLS nicht selbst terminieren (reines TCP-Passthrough) oder bereits auf einer gepatchten Version laufen.

Schritt 1 — Version prüfen und aktualisieren

# installierte Version prüfen
openssl version

# Zielversionen (gepatcht):
# OpenSSL 4.0.1 / 3.6.3 / 3.5.7 / 3.4.6 / 3.0.21 (branch-abhängig)

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade openssl libssl3

# RHEL/Alma/Rocky
sudo dnf update openssl

# aus Quelle/Custom-Builds: gegen den offiziellen OpenSSL-Tag
# der jeweiligen gepatchten Version neu bauen und ausrollen

Schritt 2 — betroffene Prozesse neu starten

# Patch allein reicht nicht: bereits aufgeblähter Speicher wird erst
# durch einen Prozess-Neustart wieder freigegeben
sudo systemctl restart nginx
# bzw. den jeweiligen TLS-terminierenden Dienst (haproxy, envoy, eigener Server)

# Speicherstand vor/nach dem Neustart vergleichen
ps -o rss,cmd -C nginx

Schritt 3 — defense-in-depth, unabhängig vom Patch

# Handshake-Timeouts eng setzen (Beispiel nginx):
# ssl_handshake_timeout 10s;

# maximale gleichzeitige Verbindungen je Worker begrenzen
# und Verbindungsraten pro Quell-IP drosseln (z. B. via fail2ban,
# nginx limit_conn/limit_req, oder auf L4 vorgelagertem Load-Balancer)

Detection / Prüfung

Version prüfen

openssl version
# bzw. je Container-Image:
docker run --rm <image></image> openssl version

Speicherverhalten beobachten

Zu HollowByte selbst wurden in den ausgewerteten Quellen keine spezifischen Kompromittierungsindikatoren veröffentlicht — die folgenden Prüfschritte sind allgemeine, aus dem beschriebenen Mechanismus abgeleitete Beobachtungspunkte:

# RSS-Speicherverbrauch des TLS-terminierenden Prozesses über die Zeit beobachten,
# unabhängig von der Zahl aktuell aktiver Verbindungen —
# ein Anstieg ohne entsprechenden Anstieg aktiver Sessions ist der Kern-Indikator
watch -n 5 'ps -o rss,cmd -C nginx'

# ungewöhnlich viele kurzlebige TLS-Verbindungen mit frühem Abbruch
# während des Handshakes prüfen (Access-/Error-Logs, Connection-Tracking)
ss -tn state syn-recv

# Speicherverbrauch nach vollständigem Verbindungsabbau kontrollieren —
# bleibt der Speicher hoch, obwohl keine aktiven Verbindungen mehr bestehen,
# ist das ein starkes Signal für bereits eingetretene Fragmentierung

Betreiberempfehlung

Mid-Market

Im nächsten regulären Wartungsfenster patchen und dabei die betroffenen Dienste neu starten — kein CVE, kein Notfall-Rollout nötig, aber auch kein Grund, es auszusitzen, da die Technik nachweislich funktioniert.

Enterprise / Multi-Site

Alle TLS-terminierenden Komponenten inventarisieren (Reverse-Proxys, Load-Balancer, Ingress-Controller, eigene OpenSSL-Einbindungen) und deren OpenSSL-Version zentral erfassen. Speicher-Monitoring um eine Kennzahl „RSS ohne aktive Sessions“ ergänzen, um künftige ähnliche Muster früher zu erkennen.

Hosting- / Plattform-Betreiber mit vielen kleinen Instanzen

Hier ist die Dringlichkeit am größten: Kleine, ressourcenbeschränkte Instanzen sind laut Testberichten am leichtesten erschöpfbar. Patch-Rollout priorisieren und Handshake-Timeouts sowie Verbindungslimits als zusätzliche Absicherung einziehen, bevor der Patch flächendeckend ausgerollt ist.

Entscheidungsblock

Zeitnah handeln, wenn: öffentlich erreichbare, kleine TLS-Terminierungspunkte auf ungepatchtem OpenSSL laufen. Reguläres Fenster genügt, wenn: bereits gepatcht oder kein eigenes TLS-Termination durch OpenSSL im Einsatz.

Fazit

HollowByte zeigt, dass nicht jede relevante Sicherheitsverbesserung ein CVE und einen CVSS-Score trägt — OpenSSL stuft die Schwäche bewusst als Hardening-Fix ein, weil kein klassischer Speicherfehler, sondern ein Ressourcen-Management-Problem vorliegt. Der Effekt ist trotzdem real und mit geringem Aufwand reproduzierbar: Ein 11-Byte-Paket genügt, um einen Server zur Vorab-Reservierung von Speicher zu bewegen, den er nie füllt, und das Zusammenspiel mit glibcs Allokator-Verhalten macht daraus dauerhafte Fragmentierung statt eines flüchtigen Effekts. Wer TLS-Terminierung mit OpenSSL betreibt, sollte diesen Patch nicht deshalb aufschieben, weil ihm die formale CVE-Nummer fehlt — Klassifikation und tatsächliches Risiko fallen hier auseinander.

Quellen

• BleepingComputer — HollowByte DDoS Flaw Bloats OpenSSL Server Memory With 11-Byte Payload

Zu HollowByte lag zum Zeitpunkt dieses Beitrags nur die genannte Quelle vor; ein offizielles OpenSSL-Advisory oder Release-Announcement mit den exakten Commit-/Changelog-Referenzen konnte nicht zusätzlich unabhängig verifiziert werden. Details wie CVSS-Bewertung, offizielle Bezeichnung und Commit-Historie sollten vor weitreichenden Entscheidungen gegen die OpenSSL-Release-Notes der genannten Versionen abgeglichen werden.