安全加固：curl_load_library() 中缺失的整数溢出检查

摘要

在 lib/system_win32.c::curl_load_library() 函数中发现了一个缺失的整数溢出检查，该问题出现在计算 DLL 路径缓冲区大小时。在 32 位 Windows 构建版本中，未经验证的大小计算可能发生回绕，从而导致堆分配空间不足，随后通过 _tcscpy() 进行无限制的字符串拷贝。尽管当前的调用点仅传递固定的、可信的字符串，并且没有发现直接的攻击向量，但存在潜在的堆损坏原语，使得此问题超出了纯粹的信息性加固范畴，并证明其符合低严重性分类。

受影响的代码

文件: lib/system_win32.c 函数: curl_load_library(LPCTSTR filename)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


UINT systemdirlen = GetSystemDirectory(NULL, 0);
if(systemdirlen) {
  size_t filenamelen = _tcslen(filename);
  TCHAR *path = curlx_malloc(sizeof(TCHAR) *
                             (systemdirlen + 1 + filenamelen));
  if(path && GetSystemDirectory(path, systemdirlen)) {
    _tcscpy(path + _tcslen(path), TEXT("\\"));
    _tcscpy(path + _tcslen(path), filename);
  }
  curlx_free(path);
}

技术细节

整数溢出条件

systemdirlen 是 UINT 类型（32位）
filenamelen 是 size_t 类型分配大小的计算方式为：

1

sizeof(TCHAR) * (systemdirlen + 1 + filenamelen)

在 32 位平台上，size_t 算术运算在溢出时会回绕。如果 filenamelen 很大，乘法运算可能溢出，导致分配的内存远小于预期。

内存安全影响

分配内存后，两次使用 _tcscpy() 而未进行任何边界检查。如果由于算术回绕导致缓冲区大小不足，这将在代码层面创建一个可靠的堆损坏条件，与当前的可达性无关。

为何是低严重性（而非信息性）

1. 存在堆损坏原语

即使当前代码路径不受攻击者控制，该函数包含一个完整的堆损坏模式（可溢出的计算大小 + 无限制的拷贝）。这超出了风格或理论问题的范畴。

2. 违反了 libcurl 自身的防御模式

代码库的其他部分明确防范了分配计算中的整数溢出（例如，vauth/ntlm.c 使用了 SIZE_MAX 检查）。这种不一致性削弱了整体安全态势，并增加了未来维护的风险。

3. 长期及供应链风险

curl_load_library() 是一个通用的内部工具。随着 libcurl 的演变或被第三方软件嵌入，未来的重构或重用可能会无意中将未经验证的输入传递给此函数，从而立即暴露出一个堆损坏缺陷。

4. 低成本、高价值的修复

这个问题可以通过一个简单的边界检查来解决，并且不会改变有效情况下的运行时行为。这使其成为一个实际的安全修复，而非纯粹的信息性观察。

建议的修复方案

在分配之前添加一个明确的溢出检查，与 libcurl 现有做法保持一致：

1
2
3
4
5
6


if(filenamelen > (SIZE_MAX / sizeof(TCHAR)) - systemdirlen - 1) {
  return NULL;
}

TCHAR *path = curlx_malloc(sizeof(TCHAR) *
                           (systemdirlen + 1 + filenamelen));

严重性评估

严重性: 低
类型: 整数溢出导致潜在的基于堆的缓冲区溢出
当前可利用性: 未发现
风险类别: 潜在的内存损坏 / 未来可达性风险

参考资料

CWE-190: 整数溢出或回绕
CWE-122: 基于堆的缓冲区溢出
CERT C: INT30-C (确保无符号整数操作不回绕)
libcurl 先例：vauth/ntlm.c 中的溢出检查

影响

目前，没有直接的攻击者可控输入能够到达此代码路径，并且在当前的 libcurl 代码库中未发现直接的利用场景。然而，此实现包含一个完整的堆损坏原语（分配大小计算中的整数溢出，随后是无限制的字符串拷贝）。如果此函数在未来重构、新增功能或第三方重用中变得可被利用，攻击者可能实现：

32 位 Windows 构建版本上的堆内存损坏
进程崩溃（拒绝服务）
潜在的任意代码执行，具体取决于分配器行为和周围内存布局

由于 libcurl 是一个广泛嵌入的库，此类潜在问题增加了软件供应链风险和维护的脆弱性。主动修复可在其变得外部可被利用之前，消除内存损坏的条件。

时间线

y_security 向 curl 提交报告。4 天前
- 补充说明：我使用 AI 来准备报告，但意外地错过了勾选 AI 披露框。对于这个疏忽，我非常抱歉。
bagder (curl staff) 关闭了报告并将状态更改为 Not Applicable。4 天前
- 此计算不可能溢出。不是安全问题。
jimfuller2024 (curl staff) 发布了评论。4 天前
- 我没看出来这会如何溢出……如果能够演示出来，我将保持开放心态……否则（除非我漏掉了什么）认为不存在安全问题。
bagder (curl staff) 请求披露此报告。3 天前
- 根据项目的透明度政策，我们希望所有报告都被披露并公开。
y_security 发布了评论。3 天前
- 我明白了。很抱歉再次打扰你们。期待与你们再次合作。
bagder (curl staff) 披露了此报告。3 天前

报告于: 2025年12月26日，UTC 时间下午1:31 报告者: y_security 报告给: curl

参与者: 报告 ID: #3479019 N/A 严重性: 低 (0.1 ~ 3.9) 披露于: 2025年12月27日，UTC 时间下午1:47 缺陷: 整数溢出 CVE ID: 无 赏金: 无 账户详情: 无

cURL 库中的整数溢出隐患：对 curl_load_library() 函数的安全加固分析

本报告详细分析了 libcurl 库 system_win32.c 文件中的 curl_load_library() 函数在计算 DLL 路径缓冲区大小时存在的一个整数溢出问题，该问题可能导致堆内存破坏，尽管当前调用路径安全，但留下了潜在的安全隐患。