缓冲区溢出漏洞：curl的Rustls后端

漏洞摘要

curl库的Rustls后端存在缓冲区溢出漏洞，该漏洞源于动态缓冲区管理中的整数溢出问题。攻击者可能利用此漏洞覆盖内存，导致应用程序崩溃或理论上实现任意代码执行。但由于需要处理接近4GB（32位系统）或18EB（64位系统）的极大文件，实际利用极不现实，因此现实风险较低。

受影响版本

所有使用Rustls后端且包含Curl_dyn_addn函数中易受攻击的动态缓冲区管理代码的curl版本均受影响。

复现步骤

未经过滤的文件输入流入memcpy函数，用于操纵应用程序内存，可能导致缓冲区溢出漏洞。

数据流

lib/vtls/rustls.c (3个步骤)

• 421:13 - bufbuf (源)
• 424:39 - buf

lib/dynbuf.c (5个步骤)

• 167:42 - const void mem
• 172:25 - mem
• 70:29 - const unsigned char mem
• 119:28 - memmemcpy
• :28 - mem
• :5 - memcpy

相关代码链接：

• https://github.com/curl/curl/tree/acdb48272a53fe97f63e5437fce27c7036a9c43e/lib/vtls/rustls.c#L421
• https://github.com/curl/curl/tree/acdb48272a53fe97f63e5437fce27c7036a9c43e/lib/dynbuf.c#L119

影响分析

如果被利用，此漏洞可能导致内存损坏，引发应用程序崩溃或实现任意代码执行。但利用条件极为苛刻：需要在32位系统上处理接近4GB的文件，或在64位系统上处理约18EB的文件。此外，现代内存保护机制（如ASLR和DEP）进一步降低了成功利用的可能性，总体风险较低。

技术细节

漏洞源于lib/dynbuf.c中的Curl_dyn_addn函数，该函数负责向动态缓冲区添加数据。函数执行大小检查以确保缓冲区有足够容量：

1
2
3

if (s->len + len > s->size) {
    /* 需要重新分配以容纳新数据 */
}

然而，如果当前缓冲区长度（s->len）与新数据长度（len）之和超过size_t的最大值，就会发生整数溢出。这导致条件s->len + len > s->size错误地评估为false，即使总大小超过分配的缓冲区容量。随后的memcpy操作将数据写入缓冲区边界之外，导致缓冲区溢出。

理论上，在处理极大文件（如证书撤销列表CRL）时可能触发此问题：

• 在32位系统上（size_t通常为32位），溢出发生在接近4GB（2³²字节）时
• 在64位系统上（size_t为64位），溢出需要约18EB（2⁶⁴字节），这在现实场景中极不现实

缓解措施

用户：避免处理接近或超过size_t大小限制的不受信任文件（如32位系统上4GB，64位系统上18EB）。在处理前尽可能验证输入文件大小。

开发者：更新Curl_dyn_addn函数以包含显式溢出检查。例如，在执行加法前验证s->len + len不超过SIZE_MAX，或使用安全算术库防止整数溢出。补丁示例：

1
2
3

if (len > SIZE_MAX - s->len || s->len + len > s->size) {
    /* 处理溢出或大小不足 */
}

时间线与响应

• 2025年3月14日 6:42 UTC：cyberguardianrd提交报告
• 2025年3月14日 7:16 UTC：curl团队确认收到报告并开始调查
• 2025年3月14日 7:23 UTC：curl团队指出Rustls后端仍标记为实验性，不视为安全问题但承认是合法bug
• 2025年3月14日 7:31 UTC：团队指出在32位系统上realloc()可能在达到2GB时失败返回NULL，实际难以触发漏洞
• 2025年3月14日 7:35 UTC：提供修复PR链接（https://github.com/curl/curl/pull/16716）
• 2025年3月14日 8:01 UTC：关闭报告并将状态设为"信息性"，指出实际难以触发且代码为实验性
• 2025年6月28日 12:26 UTC：请求披露报告
• 2025年6月30日 18:54 UTC：报告被披露

总结

虽然利用的不现实性降低了紧迫性，但在代码库中解决此问题将增强curl库的整体健壮性。本报告全面概述了漏洞、潜在影响和可操作的缓解措施，适合技术和非技术受众。