Hotdry.

Article

AUR包完整性验证机制：从CHAOS RAT供应链攻击看社区仓库安全审查

基于2025年7月AUR供应链攻击事件，剖析PKGBUILD信任边界问题，提供从源码校验、构建隔离到组织级审查流程的完整安全实践方案。

2026-06-12security

2025 年 7 月 16 日，Arch Linux 社区遭遇了一次典型的供应链攻击：攻击者以 "danikpapas" 的身份向 AUR（Arch User Repository）上传了三个看似正常的浏览器补丁包 ——librewolf-fix-bin、firefox-patch-bin和zen-browser-patched-bin。这些包在两天内被数百名用户安装，直到 7 月 18 日才被社区成员发现并移除。事后分析显示，恶意 PKGBUILD 在安装过程中从攻击者控制的 GitHub 仓库拉取代码，部署了 CHAOS 远程访问木马（RAT），并在受害系统上建立了持久化的systemd-initd进程，与 C2 服务器130.162.225.47:8080保持通信。

这起事件暴露了社区驱动仓库的核心安全困境：AUR 的设计哲学强调开放性和去中心化，任何注册用户都可以提交包，且没有预发布审查机制。这种 "信任但验证" 的模型在理想情况下依赖用户主动审计 PKGBUILD，但现实中绝大多数用户直接使用 AUR 助手（如 yay、paru）自动构建，根本不会查看构建脚本的内容。

攻击机制与信任边界

CHAOS RAT 攻击的核心在于利用了 makepkg 的执行模型。PKGBUILD 本质上是一个 Bash 脚本，其中build()和package()函数会在构建过程中以当前用户权限执行。攻击者在这三个包的 PKGBUILD 中插入了从外部 Git 仓库克隆代码的逻辑，而 makepkg 默认不会在隔离环境中运行，这意味着构建脚本可以：访问用户主目录、修改系统配置、下载并执行任意二进制文件。

更隐蔽的是攻击者的社会工程学设计。包名使用了 "-fix" 和 "-patch" 后缀，暗示这是官方浏览器的问题修复；而-bin后缀则表明这是预编译二进制包，符合 AUR 命名惯例。攻击者甚至将恶意代码托管在 GitHub 上，利用平台的可信度降低用户的警惕性。

包完整性验证的工程实践

针对 AUR 的安全使用，需要建立多层次的验证机制。

源码完整性校验是最基础的一道防线。每个 PKGBUILD 都应该包含sha256sums或sha512sums字段，用于验证下载源码的哈希值。用户在构建前应手动核对这些校验值是否与上游官方发布的一致。对于使用 Git 源的情况，应验证source字段中的提交哈希（#commit=...或#tag=...），而非依赖分支名称。

PGP 签名验证提供了更强的保证。Arch 官方仓库的包都经过开发者签名，但 AUR 包的情况参差不齐。理想的 PKGBUILD 应该包含validpgpkeys数组，并在source数组中同时下载.sig签名文件。用户可以通过makepkg --verifysource命令在构建前验证签名链的完整性。

构建隔离是阻断恶意脚本影响的关键技术。systemd-nspawn、Docker 或 systemd-machined 都可以用于创建最小化的构建环境。以 systemd-nspawn 为例，可以使用以下命令在隔离容器中构建 AUR 包：

# 创建基础容器
sudo pacstrap -c /var/lib/machines/build-container base base-devel

# 在隔离环境中构建
sudo systemd-nspawn -D /var/lib/machines/build-container \
  --bind=/path/to/pkgbuild:/build \
  --chdir=/build \
  --makepkg

这种隔离确保了即使 PKGBUILD 包含恶意代码，其影响范围也被限制在容器内部。

PKGBUILD 审查清单

对于必须使用的 AUR 包，建议建立标准化的审查流程。以下是关键检查点：

  1. 源码 URL 审查：确认source数组中的 URL 是否指向官方上游。警惕使用 CDN 镜像、个人 GitHub 仓库或短链接的情况。

  2. 网络操作审计：搜索 PKGBUILD 中的curl、wget、git clone等命令。任何在构建阶段发起的网络请求都应该有明确的必要性，且目标地址应该可验证。

  3. 权限边界检查：确认脚本中没有使用sudo或修改系统目录（如/usr/local、/etc）的操作。标准的 PKGBUILD 应该只向$pkgdir写入文件。

  4. 维护者信誉评估：查看 AUR 页面的投票数、评论历史和维护者账号的注册时间。新账号突然提交热门软件的 "补丁" 包是危险信号。

  5. 二进制包额外警惕：对于-bin包，由于没有源码编译过程，无法通过构建验证安全性。应优先选择从源码编译的包，或至少验证预编译二进制文件的哈希值与官方发布一致。

组织级防护策略

对于使用 Arch Linux 的企业环境，建议建立内部的 AUR 包审查管道。具体措施包括：

私有 AUR 镜像：维护一个内部审核过的包仓库，只有经过安全团队审查的 AUR 包才能进入。可以使用aurutils配合自定义仓库实现这一流程。

构建农场：所有 AUR 包的构建都在隔离的 CI/CD 环境中完成，构建产物经过病毒扫描和静态分析后才分发给终端用户。

运行时监控：在终端系统上部署文件完整性监控（如 AIDE、Tripwire）和网络行为分析，检测异常的进程启动和出站连接。特别是关注类似systemd-initd这种试图伪装成系统服务的进程名。

最小权限原则：限制普通用户使用 AUR 的权限，考虑使用专用的构建用户或虚拟机进行 AUR 包的安装。

结语

AUR 供应链攻击不是 Arch Linux 独有的问题，而是所有社区驱动软件仓库面临的共同挑战。PyPI、npm、RubyGems 等平台都经历过类似的恶意包事件。关键在于认识到 "开源" 不等于 "安全"，社区审查不能替代个人的安全责任。

对于个人用户，养成查看 PKGBUILD 的习惯，使用构建隔离工具，优先选择有良好维护历史的包。对于组织，建立正式的包审查流程，将 AUR 视为不可信来源，通过技术手段降低风险暴露面。正如这次 CHAOS RAT 事件所示，两天的窗口期足以让恶意代码进入数十甚至数百个系统 —— 在供应链安全领域，预防永远比事后响应更有价值。

参考来源

  • LinuxSecurity: "CHAOS RAT in AUR: When Trust in Open-Source Goes Too Far"
  • CyberSecHere: "Arch Linux AUR Breach Chaos RAT Delivered Through Malicious Packages"

security

内容声明：本文无广告投放、无付费植入。

如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。