AUR 软件包被 Infostealer 和 Rootkit 侵入

原文 ↗ Hacker News 讨论 ↗

泄露的范围和性质

  • 大约有 ~400 个 AUR 软件包被接管，主要是通过认领被遗弃的软件包并注入恶意构建步骤。
  • 载荷最初在 post_install 中使用 npm install atomic-lockfile ...；后续变种切换了工具链（例如 bun）来规避简单特征。
  • 这次活动一直在持续，新的恶意提交仍在出现；并不局限于单一的事件窗口。

检测和“我中招了吗？”

  • 分享了多个脚本 / 单行命令，用于：
    • 将已安装的 AUR 软件包与已知受影响的软件包列表交叉比对。
    • 区分“安装了但在攻击窗口期间从未更新”与“更新过且很可能已感染”。
  • 关键细微差别：仅仅安装了受影响的软件包并不够；通常需要在恶意期间更新过它。
  • 还分享了初步恶意软件分析和 rootkit 检查思路的链接；像 rkhunter 这样的通用工具对这种特定的 BPF rootkit 是否有效尚不明确。

AUR 的信任模型及其局限

  • 再次强烈提醒：AUR 明确属于“用户生成，风险自负”，更像 pastebin，而不是经过审核的仓库。
  • 许多人认为你必须：
    • 在安装前阅读每一个 PKGBUILD。
    • 在每次更新时检查 diff，包括补丁和外部来源。
  • 也有人说这在规模化场景下不现实，和指望每个人都完整阅读 EULA 差不多。

遗弃软件包与认领政策

  • 核心攻击向量：大规模认领被遗弃的软件包（有成千上万个），然后加入恶意步骤。
  • 不少人认为当前认领模型“已经坏掉”，并建议：
    • 强制新提交，而不是静默接管。
    • 清理旧的 orphan。
    • 在维护者变更时提供显著警告。
  • 有人建议采用用户名作用域的软件包名，以便让所有权更清晰。

用户实践与缓解措施

  • 很多人建议：
    • 尽可能坚持使用官方仓库；尽量少用 AUR。
    • 避免使用 AUR helper，或者至少只在手动检查 PKGBUILD diff 后再使用。
    • 警惕那些自身依赖其他 AUR 软件包、包含大量补丁集，或带有额外网络下载步骤的 AUR 软件包。
    • 将高风险软件运行在 VM/容器中，或为不同角色（工作 vs 财务）使用独立的 QEMU VM。
  • 像 traur 和其他扫描器之类的工具可以标记可疑模式（例如 orphan 接管），但并不能作为保证。

npm 的角色与更广泛的供应链风险

  • 恶意代码通过 npm（后续还通过其他 JS 工具链）分发，这强化了人们对 JS 生态经常成为供应链攻击向量的看法。
  • 有人指出，这并不是 AUR 独有的问题：PyPI、npm、cargo、浏览器扩展、Flatpak/Flathub 等也都有类似的系统性风险。

Arch 的回应与沟通

  • 一些人批评官方消息发布延迟或内容过少，并认为 AUR 本应临时“隔离”并附上明确警告。
  • 另一些人则反驳说：
    • AUR 一直都明确不经过审核。
    • 基础设施由志愿者运营；期待“企业级”的事故响应是不现实的。
  • 最终，Arch 的官方新闻条目承认了这一事件；维护者正在处理删除 / orphan 请求。

未来的防护与自动化

  • 建议的改进包括：
    • 在 helper 中对近期所有者变更、orphan 认领和异常下载（例如新的 npm/curl 使用）提供警告。
    • 可选的自动扫描（包括基于 LLM 的审查）来标记可疑的 PKGBUILD 变更，同时要认识到提示注入和“安全感假象”的风险。
    • 更强的沙箱 / VM 隔离，以及更广泛采用像 SLSA 这样的供应链框架。
  • 有人认为这“实际上标志着当前 AUR 模式的终结”；也有人认为这是一次严重但并不意外的事件，只是重申了长期以来的警示，并没有否定整个 AUR。