深入解析curl schannel.c TLS数据传输中的整数溢出漏洞

本文详细分析了curl库schannel.c文件中存在的整数溢出漏洞,该漏洞在TLS加密数据传输过程中可能导致数据大小计算错误和安全问题,并提供了完整的PoC代码和测试环境配置说明。

curl schannel.c TLS数据传输中的整数溢出漏洞分析

漏洞概述

该漏洞允许在加密数据传输过程中添加TLS缓冲区大小时发生整数溢出,这可能导致发送错误的数据大小和TLS安全问题。在Windows 10测试环境中,Windows的Schannel拒绝了构造的畸形TLS握手(SEC_E_INVALID_TOKEN),这与预期一致,漏洞代码位于:./lib/vtls/schannel.c

1
2
/* send the encrypted message including header, data and trailer */
len = outbuf[0].cbBuffer + outbuf[1].cbBuffer + outbuf[2].cbBuffer;

技术细节

在TLS连接建立后的规则中也会发生这种情况。这发生在数据传输阶段,而不是握手本身,Windows会验证TLS记录并拒绝明显畸形的记录。

curl添加三个缓冲区:outbuf[0]是TLS头部,outbuf[1]是加密数据,outbuf[2]是TLS尾部。curl在没有检查整数溢出的情况下将这三个值相加,在32位测试环境中,如果大小足够大,加法可能会溢出,导致len值变小。

这可能导致:

  • 不正确的数据传输大小
  • TLS协议违规
  • 内存安全问题
  • 最坏情况下,如果溢出导致curl发送的数据少于预期,可能绕过安全检查

测试验证

可以通过附带的概念验证进行测试,其中运行恶意HTTP服务器,任何连接到此类恶意服务器的Windows curl用户都会受到影响。实际利用的唯一可行方法需要绕过Windows Schannel的有效性检查,因为在测试中收到了SEC_E_INVALID_TOKEN拒绝畸形TLS。这也在32位Windows系统上进行了测试,其中回绕是可能的。

测试日志

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
=== Schannel Vulnerability PoC Server (Windows) ===
This server attempts to trigger the integer overflow
in curl's schannel.c by sending crafted TLS responses

[*] Initializing Winsock...
[*] Malicious server listening on port 4433
[*] Test with: curl -k https://localhost:4433
[*] Client connected
[*] Received 1815 bytes (ClientHello)
[*] Sending malicious TLS record...
[*] Sent malicious TLS records
[*] Connection closed

数学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
35
36
37
38
39
40
#define SECURITY_WIN32 1
#include <windows.h>
#include <security.h>
#include <schannel.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
    printf("Curl Schannel Integer Overflow PoC\n");
    printf("==================================\n\n");

    SYSTEM_INFO si;
    GetSystemInfo(&si);
    printf("Architecture: %s\n", si.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64 ? "64-bit" : "32-bit");
    printf("sizeof(size_t): %llu bytes\n\n", (unsigned long long)sizeof(size_t));

    SecBuffer outbuf[3];
    outbuf[0].cbBuffer = 0x80000000;
    outbuf[1].cbBuffer = 0x80000001;
    outbuf[2].cbBuffer = 0x00000000;

    size_t len = outbuf[0].cbBuffer + outbuf[1].cbBuffer + outbuf[2].cbBuffer;

    printf("Vulnerable code: len = outbuf[0].cbBuffer + outbuf[1].cbBuffer + outbuf[2].cbBuffer\n\n");
    printf("0x%08lX + 0x%08lX + 0x%08lX = 0x%llX\n", 
           (unsigned long)outbuf[0].cbBuffer,
           (unsigned long)outbuf[1].cbBuffer, 
           (unsigned long)outbuf[2].cbBuffer,
           (unsigned long long)len);

    unsigned long long expected = 0x100000001ULL;

    if(sizeof(size_t) == 4 && len != expected) {
        printf("\n*** INTEGER OVERFLOW on 32-bit! ***\n");
        printf("Expected: %llu bytes\n", expected);
        printf("Got: %llu bytes\n", (unsigned long long)len);
    }

    return 0;
}

影响版本

  • 8.15.0: 发布版本
  • 8.16.0: 开发版本

潜在影响

攻击者可以实现认证绕过,如果凭据通过TLS传输,比如发送4GB的加密认证数据,但实际上由于溢出只发送了一个字节,服务器将收到不完整的凭据。

还可能通过再次操纵TLS握手来触发大缓冲区大小,导致相同的溢出,使应用程序接收的数据少于预期,从而阻止数据泄露。

这可能导致DoS,因为当len非常小时可能出现无限循环,或者由于协议违规或重复连接尝试耗尽资源而导致连接完全挂起。

实际利用条件

攻击者需要控制或破坏TLS服务器,操纵Windows的EncryptMessage()返回特定的缓冲区大小,并在数据传输期间触发溢出。这可能表现为传输不完整的安全补丁、看似完整但实际上被截断的文件传输或被截断的API请求。

开发团队反馈

curl开发团队认为这是一个边缘情况,在实际的Windows环境中不太可能被触发,因为Schannel会阻止尝试。最终该报告被标记为"不适用"并公开披露。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计