OpenSSL behebt schwerwiegende DTLS-Speicherleck-Lücke im neuesten Release
OpenSSL hat Fixes für CVE-2026-84782 veröffentlicht, eine Schwachstelle mit hoher Kritikalität in DTLS, die zu Heap-Speicherlecks oder zum Absturz von Diensten führen kann. Updates sind für unterstützte Branches verfügbar, ältere Versionen erfordern jedoch Pre
Automatisch aus dem englischen Original übersetzt.
OpenSSL hat am 29. September Sicherheitsupdates veröffentlicht, um eine Schwachstelle mit hoher Kritikalität in der Implementierung des Datagram Transport Layer Security (DTLS) Protokolls zu beheben. Die als CVE-2026-84782 klassifizierte Lücke ermöglicht es einem Angreifer potenziell, Heap-Speicher auszulesen oder einen Denial-of-Service-Angriff durchzuführen, indem eine spezifische Race Condition während der Handshake-Retransmission ausgelöst wird. Patches sind öffentlich für neuere Branches verfügbar, während ältere Versionen nun kostenpflichtigen Premium-Support erfordern.
Was passiert ist
Die Schwachstelle betrifft das DTLS-Protokoll, das im Wesentlichen TLS für UDP-Datenverkehr adaptiert. Es wird häufig in Echtzeit-Kommunikationssystemen wie WebRTC für Sprach- und Videoanrufe eingesetzt. Das Problem tritt auf, wenn eine große Handshake-Nachricht fragmentiert gesendet wird. Wenn das Netzwerk die Übertragung mitten in der Nachricht pausiert, kann ein Timer den erneuten Versand einer früheren Nachricht auslösen. Aufgrund eines Logikfehlers verwendet die Retransmissions-Operation fälschlicherweise die Buffer-Position der pausierten großen Nachricht, anstatt zum Anfang der erneut zu sendenden Nachricht zurückzusetzen.
Diese Diskrepanz führt dazu, dass das erneut gesendete Paket Restbytes der größeren Nachricht enthält, die falsch gelabelt sind. Diese Bytes können unverschlüsselte Daten aus dem Heap-Speicher der Anwendung enthalten und sensible Informationen gegenüber dem Remote-Peer offenlegen. Im schlimmsten Fall stürzt die Anwendung ab, wenn der Lesevorgriff auf nicht gemappten Speicher zugreift. Laurent Gaffie von Secorizon meldete das Problem am 17. August, und Ryan Hooper entwickelte den Patch. OpenSSL hat nicht bestätigt, ob ein Angreifer diese Bedingung zuverlässig erzwingen kann, und es wurden keine Exploits in freier Wildbahn beobachtet.
Der Fix ist in OpenSSL 4.0.3, 3.6.5, 3.5.9 und 3.4.8 enthalten. Für Nutzer älterer Branches ist die Situation jedoch komplexer. OpenSSL 3.0 erreichte sein Ende des öffentlichen Sicherheits-Supports am 7. September. Folglich ist der Fix für Version 3.0 (veröffentlicht als 3.0.23) nur für Kunden mit Premium-Support-Verträgen verfügbar. Dieselbe Einschränkung gilt für die längst veralteten Branches 1.1.1 und 1.0.2.
Wie es funktioniert
DTLS behandelt unzuverlässige UDP-Verbindungen, indem es große Handshake-Nachrichten in kleinere Datagrams fragmentiert. Wenn eine Verbindung ins Stocken gerät, nutzt das Protokoll einen Retransmission-Timer, um Nachrichten erneut zu senden, die möglicherweise verloren gegangen sind. Der Fehler tritt in der Interaktion zwischen diesem Timer und der Fragmentierungslogik auf. Wenn eine große Nachricht teilweise gesendet und dann pausiert wird, trackt der interne Zustand die aktuelle Position im Buffer. Wenn der Timer für eine andere, frühere feuert, während die große Nachricht pausiert ist, schreibt der Code fälschlicherweise weiter von der pausierten Position aus, anstatt vom Anfang der erneut zu sendenden Nachricht.
Dies führt zu einem Paket, das vorgibt, eine Handshake-Nachricht zu sein, aber beliebige Daten aus dem Heap enthält. Da das Label falsch ist, könnte das Empfangsende diese Daten als gültigen Protokollinhalt verarbeiten, was zu Informationslecks führt. Wenn der Buffer-Overrun ungültige Speicheradressen trifft, terminiert der Prozess abrupt. Die Schwachstelle betrifft sowohl DTLS-Clients als auch -Server, und der Fix stellt sicher, dass Retransmissions den Buffer-Pointer immer korrekt zurücksetzen.
Wichtige Details
- CVE-Identifier: CVE-2026-84782, eingestuft als High Severity von OpenSSL und 8.2/10 von CISA.
- Betroffenes Protokoll: Nur DTLS; Standard-TLS über TCP ist nicht betroffen.
- Öffentliche Fixes: Verfügbar in OpenSSL 4.0.3, 3.6.5, 3.5.9 und 3.4.8.
- Eingeschränkte Fixes: OpenSSL 3.0.23, 1.1.1zj und 1.0.2zs sind nur für Premium-Support-Kunden verfügbar.
- Distributions-Updates: Ubuntu 26.04, 24.04 und 22.04 haben gepatchte Pakete veröffentlicht; Debian 13 ist gefixt, aber Debian 12 bleibt bis zum 30. September verwundbar.
- Andere Fehler: Dieses Release behebt auch 13 weitere Probleme, darunter einen Crash mit moderater Kritikalität in OpenSSL 4.0 (CVE-2026-84783).
Warum es wichtig ist
Für Entwickler, die Echtzeit-Kommunikationstools bauen, stellt diese Schwachstelle ein direktes Risiko für die Privatsphäre der Nutzer und die Verfügbarkeit der Dienste dar. Heap-Speicherlecks können Session-Keys, personenbezogene Daten oder den internen Anwendungsstatus offenlegen. Da DTLS grundlegend für WebRTC ist, muss jeder Dienst, der Sprache, Video oder Echtzeit-Datenkanäle über UDP nutzt, seine OpenSSL-Abhängigkeit überprüfen. Die Tatsache, dass kein Workaround existiert, bedeutet, dass das Update der einzige Weg zur Mitigation ist.
Der Wechsel von OpenSSL 3.0 zu ausschließlichem Premium-Security-Update stellt eine signifikante Änderung für viele Linux-Distributionen und Embedded-Systeme dar. Teams, die Long Term Support (LTS)-Versionen von Ubuntu oder Debian nutzen, die OpenSSL 3.0 bündeln, müssen sich nun auf ihre Distributions-Maintainer für Backports verlassen oder kommerziellen Support kaufen. Dies erhöht die operative Komplexität und potenzielle Kosten für die Aufrechterhaltung sicherer Infrastrukturen und unterstreicht die Notwendigkeit proaktiven Dependency-Managements.
Was Sie tun können
- Identifizieren Sie alle Dienste, die OpenSSL für DTLS verwenden, insbesondere WebRTC-Gateways oder VoIP-Server.
- Führen Sie ein Upgrade auf die neueste öffentliche Fixed-Version durch: 4.0.3, 3.6.5, 3.5.9 oder 3.4.8.
- Wenn Sie OpenSSL 3.0 verwenden, wenden Sie distributions-spezifische Patches an (z. B. Ubuntus libssl3t64-Update) und starten Sie bei Bedarf neu.
- Erwägen Sie eine Migration von OpenSSL 3.0 zu einem aktuell unterstützten Branch wie 3.5 oder 4.0, um zukünftige öffentliche Sicherheitsupdates sicherzustellen.
- Beobachten Sie Debian 12-Systeme genau, da sie verwundbar bleiben, bis ein Patch veröffentlicht wird.
- Prüfen Sie Logs auf ungewöhnliche Crashes oder Handshake-Fehler, die auf versuchte Ausnutzung hindeuten könnten.
