OpenSSL-Fehler bei DTLS-Neuübertragungen kann Heap-Daten offenlegen oder Anwendungen beenden

OpenSSL-Lücke CVE-2026-84782: DTLS-Fehler legt Heap-Daten offen, droht Absturz. Infos zu Fix-Versionen und Ubuntu-Patches.

OpenSSL-Fehler bei DTLS-Neuübertragungen kann Heap-Daten offenlegen oder Anwendungen beenden
Schwachstellen

Illustration mit KI erzeugt

Fehlerhafte Neuübertragungen bergen zwei unterschiedliche Risiken

OpenSSL hat eine schwerwiegende Schwachstelle in seiner Implementierung von Datagram Transport Layer Security (DTLS) offengelegt. Sie kann dazu führen, dass Heap-Speicher für einen entfernten Kommunikationspartner zugänglich wird oder der betroffene Prozess abstürzt.

Die als CVE-2026-84782 geführte Schwachstelle betrifft die Neuübertragung von DTLS-Handshake-Nachrichten. OpenSSL veröffentlichte am 29. September Korrekturen und stufte das Problem als hoch ein – eine Stufe unter kritisch auf der eigenen Schweregradskala.

Laurent Gaffie von Secorizon meldete die Schwachstelle am 17. August. Ryan Hooper entwickelte die Korrektur.

CISA vergab für CVE-2026-84782 am 29. September einen CVSS-Wert von 8,2 von 10. Der Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H. Die Bewertung beschreibt eine über das Netzwerk erreichbare Schwachstelle, für deren Ausnutzung weder Berechtigungen noch eine Benutzerinteraktion erforderlich sind. Die Auswirkungen auf die Vertraulichkeit sind gering, die auf die Verfügbarkeit hoch.

OpenSSL verwendet CVSS-Werte nicht für die eigenen Schweregradeinstufungen und weist darauf hin, dass externe Bewertungen erheblich von den eigenen Einschätzungen abweichen können.

Zum Zeitpunkt des CISA-Eintrags waren keine Ausnutzungsversuche bekannt. OpenSSL hatte keine Angriffe gemeldet, und CISA hatte keine Frist zur Behebung im Rahmen der Liste der bekannten ausgenutzten Schwachstellen festgelegt.

Wenn ein DTLS-Handshake pausiert, kann der falsche Speicher offengelegt werden

DTLS überträgt die Sicherheitsfunktionen von TLS auf verbindungslose Transportprotokolle wie UDP. Es kann WebRTC-Datenkanäle absichern und dabei helfen, Verschlüsselungsschlüssel für Internetanrufe auszuhandeln.

Große DTLS-Handshake-Nachrichten müssen in Fragmente aufgeteilt werden, die jeweils in ein einzelnes UDP-Datagramm passen. Nimmt eine Verbindung vorübergehend keine weiteren Daten an, kann OpenSSL das Senden einer solchen Nachricht mittendrin unterbrechen.

Während dieser Unterbrechung kann der Timer für eine Neuübertragung ablaufen. OpenSSL muss dann eine zuvor gesendete Handshake-Nachricht erneut übertragen. Der anfällige Code kann jedoch an der aktuellen Position im Puffer der pausierten, größeren Nachricht ansetzen, statt am Anfang der für die Neuübertragung ausgewählten Nachricht.

Durch diesen inkonsistenten Zustand entstehen fehlerhafte Handshake-Daten. Die erneut übertragene Nachricht erhält eine falsche Kennzeichnung und kann noch vorhandene Bytes aus der größeren, gepufferten Nachricht enthalten.

Bei der Verarbeitung dieser fehlerhaften Daten kann über die vorgesehene Puffergrenze hinaus gelesen werden. Laut OpenSSL können dabei Inhalte des Heaps als unverschlüsselte Handshake-Daten an den Kommunikationspartner gesendet werden. Reicht der Lesezugriff über den Puffer hinaus in einen nicht zugeordneten Speicherbereich, kann die Anwendung abstürzen.

Damit sind zwei Folgen möglich: die begrenzte Offenlegung von Prozessspeicher und ein Denial-of-Service. Der Ubuntu-Sicherheitshinweis USN-8847-1 beschreibt fehlerhaftes Handshake-Verhalten und einen Denial-of-Service, erwähnt jedoch nicht die von OpenSSL festgestellte Offenlegung von Heap-Speicher.

Die Schwachstelle betrifft nicht ausschließlich DTLS-Clients oder DTLS-Server. OpenSSL hat die Korrektur in beiden Rollen getestet. Es hat jedoch nicht angegeben, ob ein Angreifer zuverlässig genau in dem Moment eine Neuübertragung auslösen kann, in dem eine andere Handshake-Nachricht pausiert ist.

Behobene Versionen, aber nur eingeschränkte Optionen für nicht mehr unterstützte Zweige

Alle Versionen vor der folgenden korrigierten Version des jeweiligen aufgeführten Zweigs sind betroffen:

OpenSSL-Zweig Korrigierte Version Verfügbarkeit und Supportstatus
4.0 4.0.3 Öffentlich verfügbar; Support bis zum 14. Mai 2027
3.6 3.6.5 Öffentlich verfügbar; Support bis zum 1. November 2026
3.5 3.5.9 Öffentlich verfügbare LTS-Version; Support bis zum 8. April 2030
3.4 3.4.8 Öffentlich verfügbar; Support bis zum 22. Oktober 2026
3.0 3.0.23 Nur für Kunden mit Premium-Support verfügbar; öffentlicher Support endete am 7. September 2026
1.1.1 1.1.1zj Nur für Kunden mit Premium-Support; kein öffentlicher Support
1.0.2 1.0.2zs Nur für Kunden mit Premium-Support; kein öffentlicher Support

OpenSSL konnte nicht feststellen, ob die Zweige 3.1, 3.2 und 3.3 betroffen sind. Für sie gibt es keinen öffentlichen Support mehr.

Die Situation bei OpenSSL 3.0 ist besonders relevant für Unternehmen, die die Bibliothek selbst kompilieren oder in andere Produkte integrieren. Die letzte öffentliche Version war 3.0.22, veröffentlicht am 25. August. Version 3.0.23 ist das erste Sicherheitsupdate dieses Zweigs, das OpenSSL nicht öffentlich bereitstellt.

Dieses nur für Premium-Kunden verfügbare Update behebt sechs der 14 Schwachstellen, die am 29. September korrigiert wurden – darunter CVE-2026-84782. Unternehmen, die weiterhin das ursprüngliche OpenSSL 3.0 einsetzen, können die offizielle öffentliche Korrektur für diese Schwachstelle daher nicht beziehen.

OpenSSL empfiehlt, auf einen unterstützten Zweig zu migrieren, etwa auf 4.0 oder die LTS-Reihe 3.5, oder Support zu erwerben. Für Umgebungen, die nicht aktualisiert werden können, wurde keine Umgehungslösung veröffentlicht.

Ubuntu und Debian stellen zurückportierte Korrekturen bereit

Die Paketversionen von Linux-Distributionen stimmen nicht zwangsläufig mit den Versionsnummern der korrigierten Upstream-Versionen überein, da Maintainer Sicherheitspatches häufig zurückportieren.

Ubuntu Security veröffentlichte am 29. September 2026 den Hinweis USN-8847-1 für Ubuntu 26.04 LTS, 24.04 LTS und 22.04 LTS. Die korrigierten Pakete sind:

Ubuntu-Version Paket Korrigierte Paketversion
26.04 LTS (resolute) libssl3t64 3.5.5-1ubuntu3.6
24.04 LTS (noble) libssl3t64 3.0.13-0ubuntu3.16
22.04 LTS (jammy) libssl3 3.0.2-0ubuntu1.30

Ubuntu-Nutzer sollten das System wie gewohnt aktualisieren und anschließend neu starten, damit alle laufenden Dienste und Prozesse die korrigierten Bibliotheken laden. Wird das Paket lediglich installiert, können länger laufende Anwendungen weiterhin den anfälligen Code verwenden, der bereits in den Speicher geladen wurde.

Ubuntu Pro bietet zehn Jahre Sicherheitsupdates für mehr als 25.000 Pakete in den Paketquellen Main und Universe. Der Dienst ist für bis zu fünf Rechner kostenlos verfügbar.

Debian behob CVE-2026-84782 in Debian 13 mit Version 3.5.7-1~deb13u3 des Pakets openssl. Die Version wurde mit DSA-6531-1 veröffentlicht. Am 30. September um 07:36 UTC führte Debians Sicherheitstracker Debian 12 weiterhin als betroffen.

Administratoren sollten DTLS-Nutzung erfassen – nicht nur OpenSSL-Installationen

Die Schwachstelle ist nur relevant, wenn Software die DTLS-Implementierung von OpenSSL verwendet. Allein die Installation eines OpenSSL-Pakets belegt nicht, dass eine Anwendung den anfälligen Codepfad nutzt.

Verantwortliche sollten Dienste ermitteln, die aus dem Internet oder intern erreichbar sind und DTLS verwenden. Dazu zählen Kommunikationssoftware und Komponenten im Umfeld von WebRTC. Auch Appliances, Container, statisch gelinkte Programme und Produkte von Anbietern sollten überprüft werden: Sie können eigene OpenSSL-Kopien enthalten, statt das Paket des Betriebssystems zu nutzen.

Priorität sollten Anwendungen haben, die aus der Ferne erreichbar sind und deren Absturz Echtzeitkommunikation oder andere verfügbarkeitskritische Dienste unterbrechen würde. Auch eine Offenlegung von Heap-Speicher ist möglich. Welche Art und Menge an Speicher sich in der Praxis auslesen lässt, ist jedoch nicht bekannt.

Es wurden keine konkreten Indicators of Compromise veröffentlicht. Unerklärliche Abstürze bei DTLS-Handshakes, fehlerhafte erneut übertragene Handshake-Nachrichten und wiederholte Verbindungsabbrüche können eine Untersuchung rechtfertigen, sind aber kein bestätigter Nachweis für einen Angriff.

Dieselbe Version behebt 13 weitere Schwachstellen

Die Updates vom 29. September behoben 13 weitere OpenSSL-Schwachstellen. Das schwerwiegendste der zusammen mit CVE-2026-84782 gemeldeten Probleme ist CVE-2026-84783. OpenSSL stuft die Schwachstelle als moderat ein; sie betrifft ausschließlich OpenSSL 4.0.

Ein nicht authentifizierter Angreifer kann den Fehler aus der Ferne ausnutzen, um bestimmte TLS-Clients oder -Server mit mehreren Threads zum Absturz zu bringen, wenn diese Client-Zertifikate anfordern. Voraussetzung ist, dass mehrere Verbindungen gleichzeitig erstmals ihre Zertifikatsketten bis zum selben vertrauenswürdigen CA-Zertifikat aufbauen. Der CVSS-Wert beträgt 7,5; der Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

CVE-2026-75806 stuft OpenSSL als niedrig ein; der CVSS-Wert beträgt 5,3. Ein Angreifer kann damit eine bestehende DTLS-1.2-Verbindung mit einer AEAD-Chiffre-Suite beenden. Ein einziges zu kleines Datagramm kann den Fehler auslösen, ohne dass der Angreifer die Schlüssel der Verbindung kennen muss.

Zu den übrigen Schwachstellen mit niedrigem Schweregrad zählen fünf Probleme in der QUIC-Implementierung von OpenSSL und drei Timing-Seitenkanäle, die ECDSA- oder SM2-Operationen betreffen. Ubuntu dokumentierte unter den mitgelieferten Korrekturen außerdem Fehler, die Denial-of-Service, Lesezugriffe außerhalb von Speicherbereichen, übermäßigen Speicherverbrauch und die Verarbeitung von Zertifikaten ermöglichen.

Unternehmen sollten daher beim Beheben von CVE-2026-84782 das vollständige Update des jeweiligen Anbieters einspielen, statt zu versuchen, nur einen einzelnen Patch herauszugreifen. Die Version schließt gleichzeitig eine Reihe weiterer Angriffs- und Fehlerpfade, die über das Netzwerk erreichbar sind.

Auch interessant

Quellen

Dieser Artikel ist eine eigenständige Aufbereitung auf Basis der folgenden Quellen.

In diesem Artikel behandelte CVEs

Zurück zur Startseite

Aktuelle Cybersecurity-News

Alle Cybersecurity-News →