昨天（2022 年 11 月 1 日），OpenSSL 发布了 3.0.7 版，以修复 OpenSSL 3.0.x 加密库中的两个高危漏洞： CVE-2022-3602 和 CVE-2022-3786。 Cloudflare 不受这些漏洞的影响，因为我们的产品使用 BoringSSL。
这些漏洞是内存损坏问题，可被攻击者利用在受害者的机器中执行任意代码。CVE-2022-3602 最初宣布时被定为严重级别，但后来被降为高级别，因为这个漏洞被认为难以通过远程代码执行（RCE）利用。与之前 OpenSSL 用户几乎普遍受到攻击的情况不同，使用其他版本 OpenSSL 的软件（例如 1.1.1）的软件不易受到这种攻击。
这些问题如何影响客户端和服务器？
这些漏洞存在于负责 X.509 证书验证的代码中 —— 大多在客户端执行，用于验证服务器和提供的证书。要受到这些漏洞的影响，受害者（客户端或服务器）需要满足以下几个条件：
恶意证书需要由受害者信任的证书颁发机构（CA）签名。
受害者需要验证恶意证书，或忽略来自浏览器的一系列警告。
受害者需要运行 3.0.7 以前的OpenSSL 3.0.x 版本。
客户端受到这个漏洞影响的条件是，访问一个恶意站点，且后者提供的证书包含利用漏洞的有效负载。此外，该恶意证书必须由受信任的证书颁发机构（CA）签名。
如果运行受影响版本 OpenSSL 的服务器支持双向验证（在此情况下，客户端和服务器均提供一个有效和签名的 X.509 证书，且客户端能向服务器提交一个带有利用负载的证书），则服务器可受到攻击。
应该如何处理这个问题？
如果你正在管理运行 OpenSSL 的服务，你应该给存在漏洞的 OpenSSL 包进行修补。在 Linux 系统上，可以使用 lsof 命令确定是否有进程动态加载 OpenSSL。如下示例中，发现 NGINX 正在使用 OpenSSL。
一旦 Linux 发行版的包维护者发布 OpenSSL 3.0.7，你就可以通过更新包源和升级 libssl3 包来进行修补。在 Debian 和 Ubuntu 上，这可以通过 apt-get upgrade 命令来完成
root@55f64f421576:/# lsof | grep libssl.so.3
nginx 1294 root mem REG 254,1 925009 /usr/lib/x86_64-linux-gnu/libssl.so.3 (path dev=0,142)尽管如此，你有可能正在运行一个受影响版本的 OpenSSL，但 lsof 命令无法发现，因为你的进程是静态编译的。必须对你负责的静态编译软件进行更新，并确保在未来几天内更新你的操作系统和其他安装的软件，其中可能包含易受攻击的 OpenSSL 版本。
root@55f64f421576:/# apt-get --only-upgrade install libssl3关键要点
Cloudflare 使用 BoringSSL，因而确信在漏洞发布日期之前，该问题不会对我们造成影响。
更普遍而言，该漏洞提醒人们，内存安全仍然是一个重要问题。这个问题可能难以被利用，因为它需要一个恶意制作并由受信任 CA 签名的证书，而证书颁发机构很可能将开始验证其签名的证书不包含利用这些漏洞的有效负载。然而，鉴于问题的严重性，打补丁并将易受攻击的 OpenSSL 包升级到 OpenSSL 3.0.7 仍然很重要。