cURL双释放漏洞技术分析报告

漏洞概述

本报告分析了一个在cURL工具的实验性SSL会话导入/导出功能（SSLS-EXPORT）中发现的双释放漏洞。该漏洞位于tool_ssls_load()函数中，当处理格式异常的SSL会话文件时，可导致对同一内存区域的重复释放，可能引发程序崩溃或拒绝服务攻击。

技术细节

漏洞位置与代码分析

漏洞存在于src/tool_ssls.c文件的tool_ssls_load()函数中，具体涉及以下代码段：

1
2
3
4
5
6
7
8


// 有问题的代码段（原始版本）
if(r) {
    warnf("invalid sdata base64 encoding in line %d: %s", i, line);
    continue;
}
// ... 如果继续执行但未重置指针 ...
curlx_free(shmac);
curlx_free(sdata);

根本原因在于第83-84行的curlx_free(shmac); curlx_free(sdata);调用后，未将shmac和sdata指针重置为NULL。当后续遇到格式异常且跳过curlx_base64_decode()调用的会话数据时，这些已被释放的指针可能被再次释放。

触发条件

功能启用：编译cURL时必须启用--enable-ssls-export选项
版本范围：影响cURL v8.12.0至v8.17.0版本
输入控制：攻击者需要能够影响SSL会话文件的内容
文件格式：特定的格式异常会话文件，可绕过某些检查但触发双释放

漏洞影响

直接影响：通过特制的SSL会话文件触发双释放，可能导致程序崩溃（DoS）
潜在风险：在特定内存管理模式下，可能被利用执行任意代码
攻击前提：需要攻击者能够控制或影响SSL会话文件内容

漏洞复现步骤

从源代码构建cURL 8.17.0：

1
2


./configure --enable-debug --with-openssl --enable-static --disable-shared --enable-ssls-export
make

创建格式异常的SSL会话文件（参考报告附件中的.curl_ssl_sessions文件）

运行cURL工具触发漏洞：

1

./src/curl --ssl-sessions .curl_ssl_sessions https://example.com

修复方案

漏洞发现者已提交修复补丁（Pull Request #19588），核心修复是在释放指针后立即将其设置为NULL：

1
2
3
4
5


// 修复后的代码
curlx_free(shmac);
shmac = NULL;  // 新增：重置指针
curlx_free(sdata);
sdata = NULL;  // 新增：重置指针

这种修复方式确保了即使后续代码路径再次尝试释放这些指针，也不会导致双释放问题。

功能背景与争议

SSLS-EXPORT功能

该漏洞存在于cURL的实验性功能SSLS-EXPORT中，该功能于2025年1月9日通过提交515a21f引入。其主要目的是：

为libcurl和curl命令行添加SSL会话导入/导出功能
通过重用SSL会话加速TLS握手
支持TLSv1.3/QUIC的0-RTT早期数据功能

实验性代码的安全争议

报告中引发了关于实验性代码安全处理的讨论：

开发团队观点：

实验性标签允许新功能在投入生产前充分测试和打磨
实验性代码中的问题不被视为安全漏洞，因为明确警告了用户不要在生产中使用
这种策略使团队能够大胆创新而不必担心"世界在第一次错误时就崩溃"

安全研究员观点：

早期发现实验性功能中的安全问题有助于防止未来潜在的真实影响
实验性标签可能降低贡献者测试新功能的积极性
安全漏洞的发现应基于代码事实和实际影响范围，而非策略标签

最终，cURL团队将该报告标记为"信息性"而非安全漏洞，理由是问题存在于实验性代码中。

技术环境与工具

检测工具

漏洞发现者使用基于符号执行的自研工具发现此问题，并正在开发针对特定目标/选项的模糊测试工具。

配置要求

必须启用OpenSSL支持
必须静态编译（--enable-static --disable-shared）
必须启用SSLS-EXPORT功能

总结与建议

技术总结

该双释放漏洞由指针管理不当引起，属于经典的内存安全问题
修复方法简单有效：释放后立即置空指针
漏洞仅影响特定编译配置下的cURL工具版本

安全建议

用户层面：避免在生产环境中使用标记为实验性的功能
开发者层面：在释放动态分配的内存后始终将指针设置为NULL
项目维护层面：对实验性代码保持与生产代码相同的安全审查标准

开源协作价值

尽管存在关于实验性代码处理方式的争议，但此事件展示了开源安全研究的价值：

独立研究人员积极测试新功能
发现并负责任地报告潜在问题
提供详细的复现步骤和修复方案
促进项目代码质量的持续改进

该漏洞的发现和修复过程体现了健康开源生态系统的协作精神，即使最终未被归类为安全漏洞，其技术分析和修复仍对代码质量有积极贡献。