BERLIN / LONDON (IT BOLTWISE) – Okta beschreibt eine OpenSSL-Schwachstelle namens HollowByte, die Server per Denial-of-Service in einen blockierten Zustand bringen kann. Schon elf Bytes reichen, weil der TLS-Handshake in verwundbaren Versionen vor der echten Größenprüfung Speicher reserviert. Besonders kritisch: Durch das Zusammenspiel mit glibc kann der Heap fragmentieren, wodurch die RSS-Werte dauerhaft steigen. Betroffene sollten die OpenSSL-Pakete ihrer Distribution zeitnah aktualisieren, da das Problem in mehreren 3.x- und 4.0.x-Zweigen behoben wurde.
Okta hat eine Schwachstelle in der Verschlüsselungsbibliothek OpenSSL dokumentiert, die unter dem Namen HollowByte bekannt ist und sich vor allem als Denial-of-Service-Risiko für TLS-Server auswirkt. Im Kern geht es darum, dass ein nicht authentifizierter Angreifer bereits beim TLS-Handshake Speicher disponiert, bevor die tatsächlichen Nutzdaten eingetroffen sind oder deren echte Länge verifiziert wurde. Damit entsteht ein Zustand, in dem Threads blockieren und auf Daten warten, die nie kommen. Für Betreiber bedeutet das nicht nur eine kurzfristige Lastspitze, sondern potenziell eine anhaltende Ressourcenbindung, die ohne Eingriff in Prozesse schwer zu beenden ist.
Technisch betrachtet liegt der Hebel in einem offenbar fehlvalidierten Längenfeld, das im regulären TLS-Handshake über einen Header abgebildet wird. Laut den Okta-Forschern beschreibt dieser Header über ein vier Byte langes Format die Größe einer nachfolgenden Nachricht; diese wird in verwundbaren OpenSSL-Varianten direkt als reservierter Speicherplatz umgesetzt. Der Angreifer kann dabei eine nur elf Byte lange Nachricht senden, deren Header ein sehr großes Datenvolumen ankündigt, ohne die entsprechenden Daten nachzuliefern. Der Worker-Thread blockiert dann und wartet unbegrenzt. Entscheidend ist: Die fehlerhafte Annahme betrifft nicht die Kryptografie selbst, sondern die Speichernutzung während der Protokollverarbeitung.
Besonders brisant ist der zweite Effekt, den Okta im Zusammenspiel mit der GNU-C-Library (glibc) beschreibt: Selbst wenn OpenSSL nach dem Abbruch einer Verbindung Puffer freigibt, kehren kleine bis mittlere Speicherfreigaben nicht sofort an das Betriebssystem zurück. Stattdessen werden sie zur Wiederverwendung im Heap gehalten. Wenn ein Angreifer in Wellen gezielt Verbindungen mit zufällig angegebenen Größen auslöst, kann er verhindern, dass der Allokator freigegebene Blöcke effizient wieder nutzt. Die Folge ist eine starke Heap-Fragmentierung. Laut Okta steigt dadurch die Resident Set Size (RSS) des Servers kontinuierlich an, auch nachdem der Angreifer die Verbindung beendet hat, und ein vollständiges Zurücksetzen gelingt in der Praxis meist nur über einen Neustart des betroffenen Prozesses.
Im Marktumfeld betrifft das Risiko eine große Bandbreite von Produkten, weil OpenSSL als technologische Basis für sichere Internetkommunikation in vielen Stacks landet. Dazu zählen Webserver wie NGINX und Apache, aber auch Laufzeitumgebungen wie Node.js, Python, Ruby und PHP sowie Datenbanksysteme wie MySQL und PostgreSQL. Dass die Auswirkungen je nach Leistungsklasse variieren, zeigt sich in Okta-Testumgebungen: Bei NGINX-Setups mit geringerer Kapazität kam es zur Erschöpfung des Arbeitsspeichers. Bei leistungsstärkeren Systemen fiel die Speicherkapazität gemessen bis zu 25 Prozent, während die Bandbreite des Angriffs unterhalb typischer Alarmschwellen für Sicherheitsüberwachung blieb. Das ist ein klassisches Muster für DoS-Angriffe, die sich eher über Ressourcenverwaltung als über reine Datenrate bemerkbar machen.
Aus Wettbewerbssicht ist relevant, dass viele Betreiber zwar bereits Hardening-Konzepte wie Rate-Limits und Workload-Quotas einsetzen, aber nicht zwingend auf eine spezifische OpenSSL-Version im System-Paketmanager achten. Hier konkurrieren OpenSSL-Ökosysteme indirekt mit anderen TLS-Implementierungen und Build-Varianten, etwa LibreSSL oder spezialisierteren Forks wie BoringSSL in bestimmten Umgebungen. Selbst wenn ein Stack “sicher” konfiguriert ist, bleibt die Angriffsfläche bestehen, sobald eine verwundbare Binärbibliothek im Prozesslauf hängt. Branchenanalysten ordnen solche Speicherverwaltungsfehler meist als besonders gefährlich ein, weil sie sich schwer über standardisierte Erkennungsmuster abfangen lassen und die Wirkung in der Zeit anhält. Dazu passt auch, dass OpenSSL das Problem als Härtungsmaßnahme ohne eigene CVE-Nummer veröffentlicht hat, was den Patch-Status in vielen Fleet-Management-Prozessen dennoch nicht automatisch hervorhebt.
Der wichtigste nächste Schritt ist damit operativ: Das OpenSSL-Team hat die Korrektur in OpenSSL 4.0.1 integriert und Versionen der Reihen 3.6.3, 3.5.7, 3.4.6 und 3.0.21 zurückportiert. Die angepassten Versionen ignorieren dabei die Größenangaben im Header zunächst und erweitern den Puffer erst dann, wenn die Daten tatsächlich eingehen. Damit wird der zentrale Fehlerpfad geschlossen: Der Server reserviert nicht mehr blind großen Speicher, um auf vermeintlich große Nachrichten zu warten. Für Unternehmen heißt das auch, den Fokus auf “Patch-Verfügbarkeit” statt “CVE-Sichtbarkeit” zu legen: Automatisierte Updates sollten die OpenSSL-Paketversionen in Linux-Distributionen mit hoher Priorität prüfen. Gleichzeitig bleiben Security- und Privacy-Themen indirekt relevant, weil ein DoS die Verfügbarkeit von TLS-gesicherten Diensten beeinträchtigen kann, wodurch Authentifizierungs- und Datenzugriffsketten ausfallen.
Mit Blick auf die Zukunft wird HollowByte vor allem eine neue Runde für Secure-Engineering-Standards auslösen. Betreiber und Entwickler dürften stärker darauf achten, wie Bibliotheken Protokollfelder in Speicheroperationen übersetzen, und ob Puffergrößen früh validiert werden oder ob es “Fail-Open”-Pfadabhängigkeiten gibt. Ebenso wird es wahrscheinlicher, dass Teams zusätzliche Schutzschichten um TLS-Server herum konfigurieren: etwa begrenzte Thread-Pools, saubere Connection-Timeouts, und Strategien, die Memory-Pressure überwachen, nicht nur Netzwerktraffic. Für Entwickler ergibt sich daraus eine Chance, Testfälle für unvollständige Handshakes und böswillige Längenfelder als Bestandteil von CI-Security einzubauen. Wenn solche Muster künftig schneller erkannt werden, sinkt das Risiko, dass ein Angreifer mit minimaler Last dauerhaft maximalen Schaden an der Systemstabilität auslöst.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "HollowByte: OpenSSL-DoS durch fehlerhafte Speichernutzung mit nur elf Bytes" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "HollowByte: OpenSSL-DoS durch fehlerhafte Speichernutzung mit nur elf Bytes" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »HollowByte: OpenSSL-DoS durch fehlerhafte Speichernutzung mit nur elf Bytes« bei Google Deutschland suchen, bei Bing oder Google News!