abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · cve-2026-19445-sni-uaf
CPython ssl - Python 软件基金会
一个 TLS 服务器若为每个连接新建一个 SSLContext、设置 sni_callback，并赋值 sslobj.context = other_ctx，就可能丢弃对原始上下文的最后一个 Python 引用，而 OpenSSL 仍持有指向它的借用指针。下一次 ClientHello（TLS 1.3 的 HelloRetryRequest 就足够）会访问该指针。握手继续进行。进程可能稍后崩溃。客户端不受影响。对监听套接字进行长生命周期的包装也不受影响。
远程 TLS 客户端可以在 C 层 SNI 回调仍指向服务器的分发 SSLContext 时将其释放。握手仍会完成。存在崩溃与内存破坏窗口。本实验环境中无 RCE。
| ID | CVE-2026-19445 |
| CWE | CWE-416 |
| CVSS | 严重：9.2 CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L |
| 产品 | CPython ssl |
| 受影响版本 | < 3.12.15、3.13.0-3.13.15、3.14.0-3.14.7、3.15.0a1（3.15.0 之前） |
| 认证 | 未认证的 TLS 客户端，服务器必须进行 SNI 切换并丢弃原始上下文 |
| 许可证 | GNU Affero GPL v3.0 |
| 实验环境 | 仅 127.0.0.1 |
与一个 Python 服务器进行 TLS 通信，该服务器为连接创建新的 SSLContext、安装 sni_callback，并在该回调中赋值一个不同的上下文，然后让原始上下文被销毁。发送 SNI。强制产生第二次 ClientHello（将服务器曲线限制为 P-384，使默认的 X25519 客户端收到 HelloRetryRequest）。GC 之后，Python 对象已不存在。C 层 tlsext_servername 回调仍持有来自 SSL_CTX_set_tlsext_servername_arg 的借用 args 指针。握手在此固定状态下完成。在 ASan 下这是 use-after-free。在生产环境中，这是下一次该内存被复用时的崩溃/破坏窗口。
用进程生命周期上下文对监听套接字包装一次的服务器会保留该引用。这些不在该缺陷范围内。wrap_socket 客户端也不在缺陷范围内。
同一产品的同类遗留问题：wrap_bio 跳过主机名验证。位于 TLS 的另一侧。二者不会组合。
PSF 发布了 CVE-2026-19445。预留 issue 为 python/cpython#156293。真正的修复映射是 PR 158504 / 提交 0f63c2aa。_servername_callback 使用了借用的 OpenSSL 参数。在 SNI 切换 sslobj.context 且原始 SSLContext 被 GC 之后，第二次 ClientHello 仍会调用它。补丁通过 SSL_get_app_data -> ssl->ctx 查找上下文，并在 context_dealloc 中清除回调。
我将 CPython 自带的测试作为实验，针对 python:3.14.7-slim-bookworm 运行（3.14.7 在受影响范围内；3.14.8 是修复版本）。UAF 路径使用 MemoryBIO，不使用 TCP。
dispatch_ctx.set_ecdh_curve("secp384r1")，客户端默认使用 X25519。sni_callback 将 sslobj.context = leaf_ctx。在首次 SNI 之后，调用三次 gc.collect()，weakref.ref(dispatch_ctx) 为 None。握手仍然完成（TLS_AES_256_GCM_SHA384）。HRR 位于 _msg_callback 中（ServerHello 随机数位于偏移 6）。sni_calls=1：第二个 ClientHello 从未到达活跃的 Python 回调。
次要路径（回调切换、del ctx、抛出 LookupError）并未使 3.14.7 中止。SSLError: CALLBACK_FAILED，不可抛出的 LookupError。反例：进程生命周期上下文包装 127.0.0.1:18500 上的监听套接字。握手正常工作。弱引用保持存活。
已记录的弯路：在 leaf 以及 dispatch 上都固定 P-384，再加上将客户端锁定为仅 X25519，产生的是 NO_SUITABLE_KEY_SHARE 而非 HRR。CPython 只固定 dispatch 上下文。HRR 魔数位于 ServerHello 偏移 6，而非 2。首次探测即使在 HRR 触发时也错过了它。dispatch_ctx 在 wrap_bio 之后仍然存活，因为 server.context 持有它。只有在 SNI 切换之后它才变得可回收。障眼法：一个反向 shell。判定依据是 dispatch_ref is None 加上一次完成的握手。
cd lab
./run.sh
镜像 python:3.14.7-slim-bookworm。Compose 项目 cve-2026-19445。回环地址 127.0.0.1:18500 是负向监听包装。主/次 oracle 均为内存中的 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
在服务器的整个生命周期内，保留对每个设置了 sni_callback 的 SSLContext 的引用。升级到 3.12.15 / 3.13.16 / 3.14.8 / 3.15.0。该 C 补丁不再使用借用的 OpenSSL 参数。