Eine Schwachstelle in der Verarbeitung des DTLS-Handshakes durch OpenSSL konnte Fragmente des Speichers einer Anwendung an das andere Ende einer Verbindung senden.
OpenSSL hat die als CVE-2026-84782 geführte, schwerwiegende Schwachstelle am 29. September offengelegt und behoben. In seiner Sicherheitsmitteilung heißt es, dass der Fehler Heap-Speicher als Klartext-Handshake-Daten offenlegen oder einen betroffenen Prozess zum Absturz bringen kann, was zu einer Denial-of-Service-Situation führt.
Für Sicherheitsteams stellt sich zunächst die Frage, welche Anwendungen OpenSSLs Datagram Transport Layer Security (DTLS) verwenden, ein Protokoll zur Absicherung von Datagrammverkehr, typischerweise über UDP. Die Schwachstelle tritt auf, wenn OpenSSL eine Handshake-Nachricht erneut überträgt, während ein anderer Handshake-Schreibvorgang angehalten ist. Daher müssen Teams prüfen, wie ihre Anwendungen DTLS verwenden.
Wie die DTLS-Schwachstelle Speicher offenlegt
Das Problem tritt auf, wenn eine Handshake-Nachricht nur teilweise geschrieben wird, weil der zugrunde liegende Transport vorübergehend keine weiteren Daten annehmen kann. Wenn während dieses angehaltenen Schreibvorgangs ein Wiederübertragungs-Timer auslöst, kann OpenSSL eine frühere Nachricht erneut senden und dabei die falsche Position in einem gemeinsam genutzten Puffer verwenden.
Diese veraltete Position kann dazu führen, dass die Wiederübertragung unbeabsichtigte Bytes enthält und über das Ende des zugewiesenen Puffers hinaus gelesen wird. Diese Bytes können den Kommunikationspartner unverschlüsselt erreichen; das Lesen in einen nicht zugeordneten Speicherbereich kann stattdessen den Prozess zum Absturz bringen.
Die Sicherheitsmitteilung beschreibt außerdem einen separaten Fehler, bei dem die Wiederübertragung Verwaltungsinformationen überschreibt, die zum Fortsetzen des angehaltenen Schreibvorgangs benötigt werden. Beim Fortsetzen kann der Prozess in einem Debug-Build abgebrochen werden. Der Patch korrigiert die Position für die Wiederübertragung und verschiebt diese, solange ein Handshake-Schreibvorgang angehalten ist.
Bereits im Januar hat OpenSSL Schwachstellen behoben, die eine Ausführung von Code aus der Ferne ermöglichen konnten . Die dokumentierten Auswirkungen dieser DTLS-Schwachstelle sind die Offenlegung von Speicherinhalten und eine Denial-of-Service-Situation; die Sicherheitsmitteilung nennt die Ausführung von Code aus der Ferne nicht als mögliche Folge.
Welche OpenSSL-Versionen benötigen Updates?
Die Sicherheitsmitteilung von OpenSSL nennt für die betroffenen Entwicklungszweige folgende Zielversionen für Upgrades:
OpenSSL-Zweig | Korrigierte Version |
|---|---|
4.0 | 4.0.3 |
3.6 | 3.6.5 |
3.5 | 3.5.9 |
3.4 | 3.4.8 |
3.0 | 3.0.23 |
1.1.1 | 1.1.1zj |
1.0.2 | 1.0.2zs |
Die Sicherheitsmitteilung führt die Korrekturen für 3.0, 1.1.1 und 1.0.2 unter dem kostenpflichtigen Support auf.
Organisationen, die Distributionspakete verwenden, sollten die Sicherheitsmitteilung ihres Distributors prüfen, statt den Patch-Status ausschließlich anhand der Versionsnummer des Upstream-Projekts zu beurteilen. Ubuntu führt beispielsweise Korrekturen in Paketen wie 3.0.13-0ubuntu3.16 für Ubuntu 24.04 LTS und 3.0.2-0ubuntu1.30 für Ubuntu 22.04 LTS auf.
Was Sicherheitsteams jetzt tun sollten
Eine praktikable Reaktion beginnt damit, Anwendungen zu identifizieren, die betroffene OpenSSL-Versionen verwenden, und festzustellen, ob sie DTLS einsetzen. Bei Fragen an Anbieter zu einer möglichen Betroffenheit und verfügbaren Updates sollten auch von Anbietern verwaltete Produkte und Anwendungen mit eingebetteten Bibliothekskopien berücksichtigt werden.
Teams können Tools für das Schwachstellenmanagement zur Unterstützung bei der Erkennung und Nachverfolgung der Behebung einsetzen und anschließend gemeinsam mit Entwicklern oder Anbietern die anwendungsspezifische Betroffenheit bestätigen. Ein Bibliotheksfund ist ein Ausgangspunkt für weitere Untersuchungen.
Wenden Sie das geeignete Update des Upstream-Projekts, der Distribution oder des Anbieters an, testen Sie betroffene Dienste und prüfen Sie, ob die Bereitstellung erfolgreich war. Diese Prüfungen gehören in einen wiederholbaren Patch-Management-Prozess , der Inventarisierung, Priorisierung, Tests und die Validierung nach dem Update abdeckt.
Die Schlussfolgerung für Verteidiger ist eindeutig: Ermitteln Sie, wo betroffener DTLS-Code verwendet wird, weisen Sie jedem Update einen Verantwortlichen zu und bestätigen Sie, dass die Anwendung die gepatchte Bibliothek ausführt.