Proof-of-Concept-Lab für CVE-2026-19445, einen CPython-ssl-SNI-SSLContext-Use-after-free, bei dem ein entfernter TLS-Client den Dispatch-Kontext des Servers während des Handshakes freigibt.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · cve-2026-19445-sni-uaf
CPython ssl - Python Software Foundation
Ein TLS-Server, der pro Verbindung einen SSLContext erzeugt, sni_callback setzt und sslobj.context = other_ctx zuweist, kann die letzte Python-Referenz auf den ursprünglichen Kontext verlieren, während OpenSSL noch einen geliehenen Zeiger darauf hält. Der nächste ClientHello (TLS 1.3 HelloRetryRequest genügt) konsultiert diesen Zeiger. Der Handshake läuft weiter. Der Prozess kann später abstürzen. Clients sind nicht betroffen. Ein langlebiger Wrap des Listening-Sockets ist nicht betroffen.
Ein entfernter TLS-Client kann den Dispatch-SSLContext des Servers freigeben, während der C-SNI-Callback noch darauf zeigt. Der Handshake wird trotzdem abgeschlossen. Absturz- und Speicherkorruptionsfenster. Kein RCE in diesem Lab.
| ID | CVE-2026-19445 |
| CWE | CWE-416 |
| CVSS | Kritisch: 9.2 CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L |
| Produkt | CPython ssl |
| Betroffen | < 3.12.15, 3.13.0–3.13.15, 3.14.0–3.14.7, 3.15.0a1 vor 3.15.0 |
| Auth | nicht authentifizierter TLS-Client, Server muss SNI wechseln und den ursprünglichen Kontext verwerfen |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1 |
TLS mit einem Python-Server sprechen, der für die Verbindung einen frischen SSLContext erzeugt, sni_callback installiert und in diesem Callback einen anderen Kontext zuweist und dann den ursprünglichen sterben lässt. SNI senden. Ein zweites ClientHello erzwingen (beschränke die Server-Kurve auf P-384, damit ein Standard-X25519-Client einen HelloRetryRequest erhält). Nach der GC ist das Python-Objekt weg. Der C-Callback tlsext_servername hat noch den geliehenen args-Zeiger von SSL_CTX_set_tlsext_servername_arg. Der Handshake wird mit diesem Pin abgeschlossen. Unter ASan ist das ein Use-after-Free. In der Produktion ist es ein Absturz-/Korruptionsfenster, sobald dieser Speicher das nächste Mal wiederverwendet wird.
Server, die den Listening-Socket einmal mit einem Kontext mit Prozesslebensdauer umschließen, behalten die Referenz. Diese liegen außerhalb des Bugs. wrap_socket-Clients liegen außerhalb des Bugs.
Gleiches Produkt, verwandtes Überbleibsel: wrap_bio überspringt die Hostname-Verifikation. Entgegengesetzte TLS-Seite. Sie lassen sich nicht kombinieren.
Die PSF hat CVE-2026-19445 veröffentlicht. Das Reservierungs-Issue ist python/cpython#156293. Die eigentliche Karte ist PR 158504 / Commit 0f63c2aa. _servername_callback verwendete das geliehene OpenSSL-Argument. Nachdem SNI sslobj.context wechselt und der ursprüngliche SSLContext per GC eingesammelt wird, ruft das zweite ClientHello immer noch in ihn hinein. Der Patch schlägt den Kontext über SSL_get_app_data → ssl->ctx nach und löscht den Callback in context_dealloc.
Ich habe CPythons eigene Tests als Lab gegen python:3.14.7-slim-bookworm ausgeführt (3.14.7 liegt im betroffenen Bereich; 3.14.8 ist der Fix). MemoryBIO, kein TCP für den UAF-Pfad.
dispatch_ctx.set_ecdh_curve("secp384r1"), Client-Standard X25519. sni_callback weist sslobj.context = leaf_ctx zu. Nach dem ersten SNI, drei gc.collect()-Aufrufe, ist weakref.ref(dispatch_ctx) None. Der Handshake wird trotzdem abgeschlossen (TLS_AES_256_GCM_SHA384). HRR steht in _msg_callback (ServerHello-Random bei Offset 6). sni_calls=1: Das zweite ClientHello erreichte nie einen lebenden Python-Callback.
Sekundärer Pfad (Callback wechselt, del ctx, wirft LookupError) brach 3.14.7 nicht ab. SSLError: CALLBACK_FAILED, unraisable LookupError. Negativ: Kontext mit Prozesslebensdauer, der einen Listen-Socket auf 127.0.0.1:18500 umschließt. Handshake funktioniert. Weakref bleibt am Leben.
Bereits dokumentierte Irrwege: P-384 sowohl auf dem Leaf als auch auf Dispatch zu pinnen und den Client zusätzlich auf X25519-only festzulegen, erzeugte NO_SUITABLE_KEY_SHARE statt HRR. CPython pinnt nur den Dispatch-Kontext. Die HRR-Magic steht bei ServerHello-Offset 6, nicht 2. Die erste Sonde verpasste HRR, selbst wenn es ausgelöst wurde. dispatch_ctx ist direkt nach wrap_bio noch am Leben, weil server.context es hält. Es wird erst nach dem SNI-Wechsel einsammelbar. Theater: eine Reverse Shell. Das Orakel ist dispatch_ref is None plus ein abgeschlossener Handshake.
cd lab
./run.sh
Image python:3.14.7-slim-bookworm. Compose-Projekt cve-2026-19445. Loopback 127.0.0.1:18500 ist der negative Listen-Wrap. Primäre/sekundäre Orakel sind In-Memory-MemoryBIO.
primary_dispatch_ref_after_sni_gc='none'
primary_hrr='yes'
primary_handshake='complete'
SUCCESS CVE-2026-19445 dispatch_ctx_gc=yes handshake=complete hrr=yes secondary_crash=no CVE-2026-19445-SNI-UAF-WITNESS
Halte eine Referenz auf jeden SSLContext, der sni_callback setzt, für die Lebensdauer des Servers. Aktualisiere auf 3.12.15 / 3.13.16 / 3.14.8 / 3.15.0. Der C-Patch verwendet das geliehene OpenSSL-Argument nicht mehr.