libcurl释放后使用漏洞分析：POST请求缓冲区提前释放的风险

本文详细分析了libcurl中一个释放后使用漏洞，当应用程序在使用CURLOPT_POSTFIELDS设置POST数据缓冲区后，在curl_easy_perform调用前释放该缓冲区会导致堆内存释放后读取，可能造成进程崩溃或内存损坏。

释放后使用：当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配置观察到的信息：

协议：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 功能：alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 Largefile libz NTLM SSL threadsafe TLS-SRP UnixSockets zstd 启用的SSL后端：OpenSSL v3+

复现步骤

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

配置和构建带有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

启动本地HTTP服务器以确保客户端发送请求主体： 

1

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

创建以下PoC程序（模拟误用：设置POSTFIELDSIZE，设置POSTFIELDS指向malloc分配的缓冲区，然后在perform之前释放它）： 

 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;
}

针对本地构建的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;
  /* Release old copied data. */
  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;   /* Give to library. */
    break;

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

1
2
3

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

影响

摘要

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

comments powered by Disqus
© 2020 - 2025 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次