「深蓝洞察」2023 年度最名不副实的高危漏洞

去年此时，我们发布了「深蓝洞察」2022 年度最名不副实的“高危”漏洞，记录了漏洞版狼来了的案例。

历史的车轮滚滚向前，但总有后人重蹈覆辙。

是的，在 2023 年，狼又来了。

以下为本期深蓝洞察年度安全报告的第四篇。

2023 年 10 月 4 日，curl 的作者在 Github 发布了一篇讨论贴，预告他们将在一周后发布 curl 的新版本，并披露被修复的两个漏洞。

作者特别强调，其中一个高危漏洞 CVE-2023-38545 可能是 curl 长期以来最严重的安全问题，但同时作者又表达，出于安全考虑暂不对漏洞做任何说明，仅提醒大家准备好更新计划。

curl 通常约 8 周更新一次小版本，而此次更新打破了周期，间隔仅一个月。加上作者措辞的慎之又慎，这些不寻常立刻引来了众多人士的关注讨论。

讨论的话题主要关于两点：

一些人尝试询问漏洞的具体影响范围，作者认为提供信息会帮助定位漏洞点，拒绝回答；
另一些人对没有立即发布补丁提出了疑问或质疑，作者则表示这份预告可以帮助人们预留出时间用来安排升级，并且认为恶意攻击者也很难在一周内找出这个潜藏了多年的漏洞。

GitHub 的网友们普遍支持 curl 作者的做法，有人还搬出了去年 OpenSSL 预告 Critical 漏洞的补丁预告，来证明这种预告是有先例的。

有趣的是，援引的 OpenSSL 漏洞，正是深蓝洞察 2022 文章中提到的被错误定级的漏洞，因此也出现了对于此次漏洞被定级高危的怀疑声。

10 月 11 日，补丁如期发布，作者同时还公开了 hackerone 报告和博客。

博客介绍了问题成因：简单来说，当 curl 使用 socks5h 代理访问一个超长主机名时，如果代理响应较慢，curl 可能会发生堆溢出。

下面我们看一下漏洞的原理，这涉及到 socks5 代理的状态机的逻辑错误。

curl 可以通过 sock5 代理进行域名解析（如设置 CURLPROXY_SOCKS5_HOSTNAME 参数，或使用 socks5h:// 协议）。

curl 支持域名最长长度为 65535 字节。而 sock5 协议支持解析的主机名最长 255 字节。

显而易见，当 curl 在本地解析超过 255 字节域名的时候，漏洞触发。修复后的版本遇到这种情况直接返回错误。

curl 处理 sock5 代理的状态机函数是do_SOCKS5（在旧一些的版本中叫做 Curl_SOCKS5），它在入口根据代理类型设置了局部变量 socks5_resolve_local。由于使用了 socks5h，这个变量被赋值为 FALSE。

do_SOCKS5 对主机名长度的判断仅发生在第一次被调用时的初始化状态下。如果主机名过长，curl 会将 socks5_resolve_local 修改为 TRUE。

随后 curl 和 socks5 代理建立连接，再根据 socks5_resolve_local 选择本地或代理解析，并进行后续请求的发送。

curl 的 socks5 状态机采用了异步的思想，如果 socks5 代理的响应速度不够快，状态机函数在更新状态后会直接返回，而不是阻塞等待。等到代理响应后，do_SOCKS5 再重新被调用，根据状态值继续处理后续逻辑。

CVE-2023-38545 的问题在于：

如果 do_SOCKS5 的首次调用中没有收到代理的握手响应，后续重新调用时所处的状态不会重新检查主机名的长度，socks5_resolve_local 仅根据 socks5h 被重置为 FALSE。因此 curl 会错误地将过长的主机名交给代理去解析，过程中通过 memcpy 复制主机名到 socks 请求缓冲区时可能产生堆溢出。

下面我们分析一下，如何利用这个漏洞。

CVE-2023-38545 影响从 7.69.0 到 8.3.0 的版本，需要分版本进行说明：

从 7.75 版本开始，socks5 请求缓冲区复用了 download buffer，它所在的堆块内不存在其他数据。命令行 curl 默认设置了 100kB 的缓冲区大小——这超过了域名最大长度 65535 字节的限制，也就不会导致溢出了；libcurl 中 download buffer 的默认大小则为 16kB，存在溢出后续堆块的可能。
对于旧一些的 7.69 - 7.74 版本，memcpy 的目标 buffer 大小仅 600 字节，它位于结构体 connectdata 的开头，通过溢出可以覆盖结构体内的各类指针以及后续的堆块头等。

遗憾的是，无论是哪个版本的 curl，溢出的主机名存在空字符和其他控制字符的截断限制，这意味着溢出最多只能写入一个合法地址。

再加上程序中大量的指针解引用、未知的基地址、堆管理器的检查……种种限制，使得这个溢出很难造成程序崩溃以外的实质影响。

换句话说，这个 curl 作者以及很多发出“核弹预警”专家口中的高危漏洞，在现实中几乎无法利用。

“狼来了”重现。

不过全世界紧张了一周的运维人员们，终于可以松一口气了，毕竟虚惊一场总好过真正的核弹落地。

OpenSSL、curl，下一个喊出狼来了的会是谁？

诚然，CVE-2023-38545 的漏洞定级很难令人信服，但 curl 作者负责任的漏洞披露过程还是值得肯定的。

反观当狼真正来的时候，警报却响得不那么及时：log4j2 重磅核弹的补丁无声落地，随后引来了铺天盖地的利用；Apple 和 Google 悄悄修复在野的 libwebp 漏洞，各人自扫门前雪，而置其他厂商用户于不顾。

我们希望厂商或组织在修复真正的高危严重漏洞，尤其是供应链源头的基础组件库的漏洞时，能够负起责任，守护下游生态的安全。

参考：

[1] https://curl.se/docs/CVE-2023-38545.html

[2] https://github.com/curl/curl/discussions/12026