openssl远程代码执行漏洞

OpenSSL 的程代漏洞公告页面又更新了。这次是码执 CVE-2022-3786 和 CVE-2022-3602，两个能触发远程代码执行的行漏高危漏洞，CVSS 评分分别是程代 7.5 和 7.4。看到邮件列表里弹出的码执通知，我第一反应是行漏翻运维群——果然，已经有人在问“要不要连夜升级”。程代

这两个漏洞都出在 X.509 证书验证环节。码执攻击者构造一个恶意证书，行漏其中 email 字段或 DNS 名称字段包含超长内容，程代就能让 OpenSSL 在处理时发生缓冲区溢出。码执3602 更麻烦，行漏溢出点落在栈上，程代理论上可以被利用来执行任意代码。码执3786 虽然只导致崩溃，行漏但配合其他漏洞照样能打出组合拳。

问题在于，证书验证这个动作太常见了。TLS 握手要验，代码签名要验，S/MIME 邮件要验。任何接受外部证书的服务都可能中招。更让人头疼的是，OpenSSL 3.0.0 到 3.0.6 都受影响，而 3.0 系列恰恰是很多新部署的默认选择。

我翻了下手头的几个项目。一个用 Nginx 做反向代理的，底层链接的是系统 OpenSSL 1.1.1，暂时安全。另一个用 Python 的 cryptography 库，它捆绑了自己的 OpenSSL 3.0.5，直接命中。还有个 Go 项目，用的是标准库的 crypto/tls，完全不受影响——Go 自己实现了 TLS 栈，绕开了 OpenSSL。

这就是 OpenSSL 漏洞最烦人的地方。你永远不知道它藏在哪个依赖的哪个角落。去年 Log4Shell 至少还能靠扫描器全网扫一遍，OpenSSL 的调用链太深了。一个 Java 应用可能通过 Netty 的 tcnative 间接用了 OpenSSL，一个 Node.js 服务可能因为某个 native 模块被拖下水。查起来像考古。

升级本身倒不复杂。官方在 3.0.7 里修了这两个洞，发行版也会很快跟进。但生产环境里，升级 OpenSSL 往往意味着重启所有依赖它的进程。对于长连接服务，这就是一次不可忽视的抖动。有些团队选择先打补丁再灰度重启，有些干脆等维护窗口。攻击窗口就这么被拉长了。

更讽刺的是，这两个漏洞是 OpenSSL 团队在修复另一个问题时意外发现的。3602 的溢出点在证书的 email 字段解析代码里，那段代码已经存在好几年了。要不是有人去动它，可能还会继续潜伏。开源软件的安全就是这样，靠的是无数双眼睛，但眼睛也有打盹的时候。

我最后决定先把 Python 服务里的 cryptography 升到最新版，Nginx 那台等下周维护窗口。至于那个 Go 项目，什么都不用做。这种时候，技术选型的前瞻性就体现出来了。不是每个团队都有这种运气，大多数人的现实是：打开终端，敲下 openssl version，然后开始祈祷。

如果你还没查，现在就去查。别等 PoC 公开了再动手，那时候扫描器已经满天飞了。