漏洞报告 #3355213 - POST缓冲区在传输前释放导致的释放后使用问题

摘要

我在libcurl中本地复现了一个堆释放后使用漏洞，通过设置CURLOPT_POSTFIELDSIZE和CURLOPT_POSTFIELDS指向堆缓冲区，然后在curl_easy_perform之前释放该缓冲区。AddressSanitizer（ASan）在请求发送路径中报告了堆释放后使用读取。这展示了当传递给libcurl的POST数据缓冲区在传输之前被释放时发生的错误类型。

AI使用说明：PoC和验证是在我的机器上手动执行的。AI辅助用于帮助构建此报告结构。

受影响版本

从GitHub获取的存储库构建（CMake配置报告：curl版本=[8.17.0-DEV]），在macOS上使用AppleClang和ASan构建。

从CMake配置观察：

1
2
3


Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 Largefile libz NTLM SSL threadsafe TLS-SRP UnixSockets zstd
Enabled SSL backends: OpenSSL v3+

复现步骤

这些是我本地在ASan下复现堆释放后使用问题的步骤。

1. 使用AddressSanitizer配置和构建libcurl

1
2
3
4
5
6
7
8


cmake -S . -B build-asan \
  -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DBUILD_SHARED_LIBS=ON \
  -DCURL_USE_LIBPSL=OFF \
  -DCMAKE_C_FLAGS='-fsanitize=address -fno-omit-frame-pointer' \
  -DCMAKE_SHARED_LINKER_FLAGS='-fsanitize=address' \
  -DCMAKE_EXE_LINKER_FLAGS='-fsanitize=address'
cmake --build build-asan -j 8

2. 启动本地HTTP服务器确保客户端发送请求体

1

python3 -m http.server 18080 --bind 127.0.0.1 &

3. 创建以下PoC程序

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


#include <curl/curl.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>

int main(void) {
  curl_global_init(CURL_GLOBAL_DEFAULT);
  CURL *h = curl_easy_init();
  if(!h) return 1;

  const char *url = "http://127.0.0.1:18080/";
  curl_easy_setopt(h, CURLOPT_URL, url);
  curl_easy_setopt(h, CURLOPT_VERBOSE, 1L);
  curl_easy_setopt(h, CURLOPT_CONNECTTIMEOUT_MS, 2000L);
  curl_easy_setopt(h, CURLOPT_TIMEOUT_MS, 3000L);

  const char payload[] = "test data";
  size_t n = sizeof(payload) - 1;

  char *cp = (char*)malloc(n);
  memcpy(cp, payload, n);

  curl_easy_setopt(h, CURLOPT_POSTFIELDSIZE, (long)n);
  curl_easy_setopt(h, CURLOPT_POSTFIELDS, cp);

  free(cp); // 当libcurl发送请求体时发生释放后使用

  CURLcode res = curl_easy_perform(h);
  fprintf(stderr, "perform result: %d\n", (int)res);

  curl_easy_cleanup(h);
  curl_global_cleanup();
  return 0;
}

4. 针对本地构建的ASan libcurl编译和运行PoC

1
2
3
4
5
6
7
8
9


# 针对新构建的ASan libcurl编译PoC
cc -fsanitize=address -fno-omit-frame-pointer -I include \
   build-asan/poc_uaf.c build-asan/lib/libcurl.dylib \
   -o build-asan/poc_uaf_local

# 使用ASan运行并确保可执行文件找到本地libcurl
DYLD_LIBRARY_PATH=build-asan/lib \
ASAN_OPTIONS=halt_on_error=1:detect_invalid_pointer_pairs=1:strict_string_checks=1:strict_memcmp=1 \
./build-asan/poc_uaf_local

支持材料/参考

下面是我运行PoC时观察到的实际ASan报告：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


*   Trying 127.0.0.1:18080...
* Established connection to 127.0.0.1 (127.0.0.1 port 18080) from 127.0.0.1 port XXXXX 
* using HTTP/1.x
=================================================================
==XXXXX==ERROR: AddressSanitizer: heap-use-after-free on address 0xXXXXXXXXXXXX at pc 0xXXXXXXXXXXXX bp 0xXXXXXXXXXXXX sp 0xXXXXXXXXXXXX
READ of size 9 at 0xXXXXXXXXXXXX thread T0
    #0 0xXXXXXXXX in __asan_memcpy+0xXXX (libclang_rt.asan_osx_dynamic.dylib+0xXXXXX)
    #1 0xXXXXXXXX in cr_buf_read sendf.c:1316
    #2 0xXXXXXXXX in Curl_client_read sendf.c:1223
    #3 0xXXXXXXXX in add_from_client request.c:349
    #4 0xXXXXXXXX in Curl_bufq_sipn bufq.c:574
    #5 0xXXXXXXXX in Curl_req_send request.c:407
    #6 0xXXXXXXXX in Curl_http http.c:2926
    #7 0xXXXXXXXX in multi_runsingle multi.c:2508
    #8 0xXXXXXXXX in curl_multi_perform multi.c:2771
    #9 0xXXXXXXXX in curl_easy_perform easy.c:846
    #10 0xXXXXXXXX in main (poc_uaf_local+0xXXXX)

0xXXXXXXXXXXXX is located 0 bytes inside of 9-byte region [...] 
freed by thread T0 here:
    #0 0xXXXXXXXX in wrap_free (libclang_rt.asan_osx_dynamic.dylib+0xXXXXX)
    #1 0xXXXXXXXX in main (poc_uaf_local+0xXXXX)

previously allocated by thread T0 here:
    #0 0xXXXXXXXX in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib+0xXXXXX)
    #1 0xXXXXXXXX in main (poc_uaf_local+0xXXXX)

SUMMARY: AddressSanitizer: heap-use-after-free in __asan_memcpy
==XXXXX==ABORTING

此错误使用上述步骤可一致复现。

代码位置（观察到的）

ASan标记UAF的读取路径（基于回溯）：lib/sendf.c中的cr_buf_read，在发送期间请求体缓冲区被memcpy复制的位置，例如围绕此函数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 1300:1323:curl/lib/sendf.c
static CURLcode cr_buf_read(struct Curl_easy *data,
                            struct Curl_creader *reader,
                            char *buf, size_t blen,
                            size_t *pnread, bool *peos)
{
  struct cr_buf_ctx *ctx = reader->ctx;
  size_t nread = ctx->blen - ctx->index;
  ...
  memcpy(buf, ctx->buf + ctx->index, nread);
  ...
  return CURLE_OK;
}

当前树中的确切memcpy行：

1
2
3
4


if(nread > blen)
  nread = blen;
memcpy(buf, ctx->buf + ctx->index, nread);
*pnread = nread;

关于用户提供的POST数据如何存储的上下文：lib/setopt.c更新s->postfields并管理STRING_COPYPOSTFIELDS在CURLOPT_COPYPOSTFIELDS / CURLOPT_POSTFIELDS上的所有权。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


case CURLOPT_COPYPOSTFIELDS:
  ...
  s->postfields = s->str[STRING_COPYPOSTFIELDS];
  s->method = HTTPREQ_POST;
  break;

case CURLOPT_POSTFIELDS:
  s->postfields = ptr;
  /* 释放旧的复制数据。 */
  Curl_safefree(s->str[STRING_COPYPOSTFIELDS]);
  s->method = HTTPREQ_POST;
  break;

OS/400 CCSID包装器（根本原因模式）

当处理具有显式大小和转换的CURLOPT_COPYPOSTFIELDS时，包装器将转换后的缓冲区传递给CURLOPT_POSTFIELDS，并将其分配给STRING_COPYPOSTFIELDS，但在返回之前释放相同的缓冲区。

传递转换后的缓冲区并分配给STRING_COPYPOSTFIELDS：

1
2
3


result = curl_easy_setopt(easy, CURLOPT_POSTFIELDS, s);
data->set.str[STRING_COPYPOSTFIELDS] = s;   /* 给予库。 */
break;

在函数结束时释放缓冲区：

1
2
3


va_end(arg);
free(cp);
return result;

影响

摘要： 基于直接观察，在设置CURLOPT_POSTFIELDS（具有显式CURLOPT_POSTFIELDSIZE）后释放应用程序提供的POST体缓冲区会导致libcurl在传输期间解引用已释放的内存，导致进程崩溃（堆释放后使用读取）。虽然此演示是本地误用PoC，但它显示了当客户端在curl_easy_perform之前无意中释放POST缓冲区时的具体内存损坏/DoS风险。

时间线

4天前 - giant_anteater向curl提交报告
4天前 - bagder（curl工作人员）发表评论致谢
4天前 - bagder引用文档说明此为预期行为
4天前 - bagder关闭报告并将状态更改为"不适用"
4天前 - giant_anteater澄清问题在于curl自身的OS/400 CCSID包装器
3天前 - bagder重新打开报告
3天前 - monnerat加入报告作为参与者
2天前 - bagder关闭报告并将状态更改为"信息性"

技术讨论

该漏洞涉及curl的OS/400 CCSID包装器（packages/OS400/ccsidcurl.c）中的确定性释放后使用/双重释放问题，当CURLOPT_COPYPOSTFIELDS与显式大小+非ASCII转换一起使用时发生。包装器将堆缓冲区交给libcurl然后释放它，导致：

在POST体发送期间的UAF（潜在的堆数据暴露）
在句柄清理时的双重释放（崩溃/DoS）

建议修复：在所有权转移后清除cp：

1
2
3


result = curl_easy_setopt(easy, CURLOPT_POSTFIELDS, s);
data->set.str[STRING_COPYPOSTFIELDS] = s;
cp = NULL;  /* 所有权已转移 */

最终状态

报告被标记为"信息性"，不被视为安全问题，主要原因：

涉及的函数既不是公共API也不是文档化的API函数
如果触发带有错误的代码路径，问题会在作业日志中记录从而暴露它
攻击者不太可能触发此问题，且利用该问题以受控方式泄露敏感数据的可能性几乎不可能

该漏洞已在代码库中修复。

libcurl POST缓冲区释放后使用漏洞深度分析

本文详细分析了libcurl中一个POST缓冲区释放后使用漏洞，包括漏洞复现步骤、技术原理和影响评估，涉及堆内存管理和HTTP请求处理机制。