Laut Okta liegt das Problem im Aufbau von TLS-Handshake-Nachrichten. Jede dieser Nachrichten beginnt mit einem 4-Byte-Header, darunter ein drei Byte großes Längenfeld, das die Größe der nachfolgenden Handshake-Daten angibt. Verwundbare OpenSSL-Versionen allokieren den angekündigten Speicher bereits vor dem Empfang der Nutzdaten und prüfen deren tatsächliche Größe erst danach.

Der Server vertraut also den Angaben im Paket, ohne den Inhalt vorher zu validieren. Okta beschreibt den Effekt so: Der Worker-Thread blockiert anschließend und wartet unbegrenzt auf Daten, die nie eintreffen werden. Ein nicht authentifizierter Angreifer kann HollowByte auslösen, indem er eine TLS-Verbindung öffnet und ein 11 Byte großes präpariertes Paket sendet, dessen Header einen deutlich größeren Nachrichtenkörper ankündigt.

Wird dieses Verfahren über viele Verbindungen hinweg wiederholt, reserviert der Server mit vergleichsweise geringem eingehendem Datenvolumen große Mengen Arbeitsspeicher. Nach Beobachtung der Okta-Forscher gibt OpenSSL die Puffer zwar frei, sobald eine Verbindung abbricht. Die GNU C Library, also glibc, geht mit dem Speicher jedoch anders um und gibt kleine bis mittlere Allokationen nicht sofort an das Betriebssystem zurück, sondern hält sie zur möglichen Wiederverwendung vor.

Gerade daraus ergibt sich der dauerhafte Effekt. Werden Wellen von Verbindungen mit zufällig variierten, im Header behaupteten Größen gestartet, kann der Speicherverwalter die freigegebenen Blöcke laut Okta nicht sinnvoll wiederverwenden. Der Heap fragmentiert stark, die Resident Set Size des Servers steigt kontinuierlich an. Selbst wenn der Angreifer die Verbindungen trennt, bleibt der Speicherverbrauch dauerhaft aufgebläht. Den belegten Speicher vollständig zurückzugewinnen, ist laut Okta nur durch einen Neustart des Prozesses möglich.

In Tests mit NGINX zeigte Okta, dass sich Systeme mit wenig Kapazität leicht des Arbeitsspeichers berauben lassen. Leistungsstärkere Server können demnach bis zu 25 Prozent ihres Speichers verlieren, während die für den Angriff nötige Bandbreite unter typischen Schwellen für Sicherheitswarnungen bleibt.

Behoben wurde das Problem in OpenSSL 4.0.1. Zudem wurde der Fix auf die Versionen 3.6.3, 3.5.7, 3.4.6 und 3.0.21 zurückportiert. Diese Fassungen vergrößern den Puffer nun erst dann, wenn die Daten tatsächlich eintreffen, und ignorieren bloße Längenangaben im Header.

Obwohl OpenSSL die Änderung als Härtungsmaßnahme und nicht als Sicherheitslücke behandelt hat, empfiehlt Okta, die OpenSSL-Pakete der jeweiligen Distribution umgehend zu aktualisieren. Eine Kennung wurde der Schwachstelle nicht zugewiesen.