一个名为 TARmageddon (CVE-2025-62518) 的逻辑漏洞在流行的 Rust 异步 TAR 解析库 tokio-tar 及其多个分支中被发现。该漏洞源于解析器在处理 PAX 和 ustar 头信息不一致时产生的混乱，允许攻击者“走私”额外的文件到归档中，从而可能导致文件覆盖、供应链攻击和远程代码执行。由于最受欢迎的 tokio-tar 库已无人维护，修复工作变得异常复杂，凸显了开源生态中“弃儿软件”（Abandonware）带来的系统性风险。用户被敦促立即升级到已打补丁的活跃分支，如 astral-tokio-tar。
什么是 TARmageddon 漏洞？
这是一个解析器不同步的缺陷，当处理一个特制的嵌套 TAR 文件时会触发。攻击者可以利用这个漏洞，在 TAR 提取过程中“走私”额外的、未在清单中声明的文件。
- 核心问题: 解析器在处理一个文件条目时，其 PAX 扩展头 和 ustar 标准头 中的文件大小信息不一致。
- 主要影响:
- 在提取目录内实现任意文件覆盖。
- 通过构建系统和包管理器进行供应链攻击。
- 绕过安全扫描工具的物料清单 (BOM) 检查。
- 波及范围: 漏洞影响了多个重要项目，包括
uv(一个极速 Python 包管理器)、testcontainers和wasmCloud。
开源“弃儿”带来的挑战
这次漏洞披露过程之所以特殊且困难，是因为下载量最大（超过500万次）的 tokio-tar 库似乎已成为无人维护的“弃儿软件”。
在一个正常的修复流程中，上游主仓库发布一个补丁，所有下游用户都能继承修复。但这次，由于无法依赖原项目维护者，修复工作被迫以一种去中心化的方式进行协调，涉及一个复杂的分支链条：
async-tar (根项目) ➡️ tokio-tar (最流行但已废弃) ➡️ krata-tokio-tar (曾由 Edera 维护) ➡️ astral-tokio-tar (由 Astral 积极维护)
这次经历凸显了当关键漏洞出现在流行的、但已被遗弃的开源依赖中时，确保大规模修复所面临的严峻挑战和低效率。
技术原理：解析器如何被欺骗
漏洞的根源在于解析器在确定文件数据边界时的逻辑不一致。
- 正常情况: 解析器读取文件头，确定文件大小，然后跳过相应大小的数据块，接着处理下一个文件头。
- 漏洞触发:
- 一个文件条目同时拥有 PAX 头和 ustar 头。
- PAX 头正确地指明了文件大小，例如 1MB。
- ustar 头却错误地将文件大小标为 0。
- 脆弱的解析器错误地采信了 ustar 头的大小，只前进了 0 字节。
- 因此，它没有跳过那 1MB 的实际文件数据（它本身是一个嵌套的 TAR 归档），而是立即开始将这个嵌套归档的内部文件头误认为是外部归档的合法文件。
最终，安全扫描工具看到的是一个无害的归档，而实际提取时，隐藏在内部归档的恶意文件被释放出来。
具体的攻击场景
Python 构建劫持: 攻击者上传一个恶意 Python 包。包的外层 TAR 包含一个合法的
pyproject.toml文件，但隐藏的内层 TAR 包含一个恶意的版本。当uv等包管理器安装此包时，恶意的配置文件会覆盖合法的配置文件，导致在开发者机器或 CI/CD 系统上执行任意代码。容器镜像投毒:
testcontainers等容器测试框架在分析镜像层时，如果使用脆弱的库来提取 TAR 文件，就可能被欺骗。隐藏的内部文件可以污染测试环境或破坏供应链。安全扫描绕过: 一个系统可能分为“扫描/批准”和“提取/部署”两个阶段。安全扫描器分析外层无害的 TAR 文件并予以批准。然而，在提取阶段，脆弱的库会释放出未经扫描和批准的隐藏文件，从而绕过安全控制。
如何修复与缓解
最直接的解决方案是立即升级或迁移。
- 首选方案: 如果您依赖
tokio-tar，请迁移到一个积极维护且已打补丁的分支，例如astral-tokio-tar。 - 替代方案:
- 切换到标准的、非异步的
tar库，它不受此漏洞影响。 - 在代码中增加运行时缓解措施，例如：
- 验证提取出的文件数量是否与预期的清单一致。
- 在提取后扫描目录以检测意外文件。
- 在沙箱环境中进行提取，并限制文件数量和大小。
- 切换到标准的、非异步的
关于 Rust 与安全边界的思考
TARmageddon 的发现提醒我们一个重要事实：
Rust 并非安全的银弹。虽然它能极大地减少内存安全漏洞（如缓冲区溢出），但它无法消除逻辑错误——而这次的解析不一致问题，本质上就是一个逻辑缺陷。
这个漏洞的演化过程揭示了一个普遍的开源困境：即使是用现代安全语言编写的流行代码，也可能因为无人维护而给其数百万下游用户带来风险。这再次强调了纵深防御的重要性，即不能仅仅依赖语言的安全性，还需要通过强大的安全边界和设计来确保关键路径不受影响。