xz-utils 后门事件复盘：一次险些瘫痪全球 Linux 的"完美供应链投毒" | ZapcoMan's world

一个匿名攻击者，用三年时间”养成”一个可信维护者身份，把一个隐蔽后门塞进了全球几乎所有 Linux 发行版都在用的压缩库。
如果不是一位微软工程师偶然发现 SSH 登录慢了 0.5 秒，这场攻击可能已经得手。

---

引言：0.5 秒的延迟，揭开一场三年阴谋

2024 年 3 月，微软工程师 Andres Freund 在跑性能测试时，注意到一个奇怪的现象：SSH 登录的加密操作突然慢了约 0.5 秒，CPU 占用也异常偏高。

换作别人，可能只是抱怨一句”机器又卡了”。但 Freund 决定追查到底。这一查，查出了一个可能瘫痪全球 Linux 系统的后门——而它被埋藏的地方，是几乎所有 Linux 发行版都依赖的基础压缩库 xz-utils（提供 liblzma）。

更惊人的是背后的故事：这个后门，是一名匿名攻击者用了整整三年时间，通过社交工程”养成”一个可信的维护者身份，再一步步渗透进 xz 项目的核心维护团队后才植入的。

一句话定义它：

xz-utils 事件 = 一场”耐心到极致”的供应链投毒——攻击者不靠 0day，靠的是”三年磨一剑”的人设经营。

---

一、事件概览

属性	信息
被投毒项目	xz-utils（liblzma 压缩库）
后门 CVE	CVE-2024-3094（CVSS 10.0，最高危）
后门类型	供应链后门 + SSH 认证绕过（RCE 预置）
影响版本	xz 5.6.0 / 5.6.1（2024 年 2-3 月发布）
攻击者	化名 “Jia Tan”（JiaT75），身份未明
潜伏时长	约 2021 年启动，持续至 2024 年 3 月被发现
发现者	微软工程师 Andres Freund
潜在危害	全球 Linux 发行版（Debian、Fedora、openSUSE 等）若未及时回滚，将面临 SSH 认证被绕过

关键时间线：

2021        ── "Jia Tan" 首次以匿名身份接触 xz 项目
     │
2022        ── 逐步提交"看似无害"的补丁，建立贡献者信誉
     │
2022-2023   ── 通过社工排挤原维护者，逐步获得更核心的维护权限
     │
2024.02     ── 后门代码被混入 xz 5.6.0 的发布产物（tarball）
     │
2024.03     ── ⭐ Andres Freund 发现 SSH 异常，全球紧急回滚
     │
2024.03.29  ── CVE-2024-3094 公开，各大发行版紧急撤销受影响版本

---

二、攻击者的”人设经营”：三年磨一剑的社工

xz-utils 事件最令人震撼的，不是后门技术本身，而是攻击者如何”合法地”获得投毒权限。

2.1 “Jia Tan” 的登场

• 2021 年，一个化名 “Jia Tan”（账号 JiaT75）的用户开始向 xz 项目提交看似正常的代码贡献。
• 这些早期提交无害、质量尚可，甚至修复了一些真实的小问题，逐步赢得了社区的信任。
• 与此同时，攻击者还操纵了多个”傀儡账号”，在邮件列表里抱怨 xz 维护缓慢、催促换人，制造舆论压力。

2.2 排挤原维护者

xz 的原维护者 Lasse Collin 长期”单打独斗”、精力有限。攻击者抓住这一点：

"Jia Tan" 持续积极贡献，赢得信任
        ↓
傀儡账号在邮件列表抱怨"项目缺乏维护""更新太慢"
        ↓
舆论压力下，社区默认"Jia Tan"成为事实上的共同维护者
        ↓
"Jia Tan" 获得提交权限，逐步接管核心维护

这是典型的**”信任置换”攻击**——攻击者不是”黑进”项目，而是通过长期的”好人表现”和舆论操纵，被社区”请”进了核心圈。

2.3 为什么这种社工极难防范？

• 开源社区的贡献机制天然开放——任何人只要能提交好代码，就能获得信任。
• 维护者精力有限——像 xz 这种”冷门但关键”的基础设施项目，往往靠一两个”义务维护者”苦撑，极易被”热情的新人”填补。
• “傀儡账号”难以识别——攻击者的舆论操纵账号彼此独立，社区很难判断它们是否”一伙的”。

这正是 xz-utils 事件最大的警示：开源世界的信任机制，被一个耐心的攻击者用三年时间”合法地”击穿了。

---

三、代码级攻击链：后门如何藏进 liblzma 并劫持 SSH

xz-utils 后门的技术设计堪称”教科书级”的隐蔽。我们从代码层面还原它的完整链条。

3.1 后门不藏源码，藏在”发布产物”里

攻击者最狡猾的一招是：后门代码不在公开的源码仓库里，而是藏在”打包发布的 tarball”里。

公开 GitHub 源码仓库（干净，无后门）
        ↓
攻击者篡改"发布脚本"（build-to-host.m4 等）
        ↓
在打包 tarball 时，动态注入后门二进制文件
        ↓
下游发行版拿到的 tarball = 被投毒的"干净源码"

这意味着：即便有人审计了 GitHub 上的源码，也发现不了问题——因为后门只在”打包那一刻”被注入。

3.2 后门的分阶段投递

后门并非一次性生效，而是层层嵌套、只在特定条件下激活：

阶段1：篡改构建脚本（build-to-host.m4）
        ↓ 在特定构建环境（Debian/RPM 打包）下触发
阶段2：注入一个恶意测试文件（bad-3-corrupt_lzma2.xz）
        ↓ 该文件在构建时被"解包"出恶意代码
阶段3：篡改 liblzma 的编译产物，植入后门
        ↓ 后门 hook 了 RSA 签名验证函数
阶段4：劫持 SSH（sshd）的认证流程
        ↓ 特定条件下，绕过 SSH 认证（预置 RCE 能力）

3.3 核心原理：劫持 SSH 的 RSA 签名验证

后门的”最终目标”是劫持 sshd 的认证流程。其技术核心是函数 Hook：

// 概念示例：后门如何劫持 SSH 认证（脱敏还原，仅供安全教育）
// 后门被编译进 liblzma，而 liblzma 恰好是 systemd 的依赖
// systemd 又恰好被 sshd 依赖 → 后门得以加载进 sshd 进程

// 后门 hook 了 RSA 签名验证函数，概念逻辑如下：
bool rsa_verify_hooked(const unsigned char *sig, const unsigned char *data) {
    // 1. 若签名匹配攻击者预置的"后门密钥" → 直接放行（绕过认证）
    if (memcmp(sig, BACKDOOR_MAGIC, BACKDOOR_MAGIC_LEN) == 0) {
        return true;   // 认证通过，攻击者获得 SSH 权限
    }
    // 2. 否则走正常验证逻辑
    return real_rsa_verify(sig, data);
}

这条链的”巧合”之处（也是精妙之处）：

• liblzma 是 systemd 的依赖，而 systemd 又是 sshd 的依赖。
• 因此，后门只要藏进 liblzma，就能”顺藤摸瓜”加载进 sshd 进程。
• 攻击者精确选择了这条依赖链的”咽喉”，实现”一处投毒、全局生效”。

这种”通过底层库劫持上层服务“的手法，是供应链攻击的终极形态——它不需要直接攻击目标，只需要污染一个”所有人都在用”的基础组件。

---

四、为什么 0.5 秒的延迟能救命？

Andres Freund 之所以能发现后门，靠的是对性能异常的敏感：

• 后门在 sshd 进程中多做了一次 RSA 签名验证的额外计算，导致登录慢了约 0.5 秒。
• 同时 CPU 占用率也异常偏高（后门在暗中执行额外逻辑）。
• Freund 用 perf 等工具顺藤摸瓜，最终定位到 liblzma 的异常。

这带来的启示是：

最隐蔽的后门，也可能在性能上留下蛛丝马迹。 那些”看似无关紧要”的性能回归、CPU 异常、延迟波动，背后可能藏着惊天阴谋。

---

五、供应链攻击的”基础设施危机”

xz-utils 事件揭示了一个更深刻的问题——开源软件的基础设施，比我们想象的脆弱得多：

5.1 “关键且无人维护”的悖论

• xz-utils 是几乎所有 Linux 发行版的基础依赖，但它的维护者长期只有一个人（Lasse Collin）。
• 这类”关键但冷门、无人问津“的项目，被称为开源世界的”bus factor = 1“（巴士因子为 1，即维护者一旦”出事”，项目就无人接手）。

5.2 与 Log4Shell 的对比

维度	Log4Shell（2021）	xz-utils（2024）
组件	Log4j（Java 日志库）	xz/liblzma（压缩库）
漏洞性质	无意的代码漏洞	蓄意的供应链后门
攻击者	利用者（被动发现）	主动长期渗透投毒
关键差异	“无心之失”	“蓄意谋杀”

Log4Shell 是”软件写坏了”，xz-utils 是”软件被精心改坏了”。后者远比前者可怕——因为它意味着，我们依赖的每一行代码，都可能来自一个”伪装了三年的敌人”。

---

六、检测与防御：如何应对”下一个 xz”？

对机构与开发者

1. 审计”构建产物”，而非只审计”源码”：xz 后门就藏在 tarball 里。需对发布产物做独立的完整性校验与差异比对。
2. 监控性能异常：登录延迟、CPU 异常的”微小变化”，可能是后门在作祟——建立性能基线。
3. 供应链依赖清单（SBOM）：清晰掌握自己依赖了哪些组件、哪些组件”关键且无人维护”。
4. 隔离与最小权限：关键服务（如 SSH）应运行在受限环境中，减少被底层库劫持的杀伤面。
5. 支持关键开源项目：xz 事件后，业界开始反思”关键基础设施靠义务维护者苦撑”的现状，推动企业赞助、多人维护。

对个人

• 及时更新系统补丁，关注发行版的安全公告。
• 对”来路不明”的软件包、第三方源保持警惕。
• 使用官方源与签名校验，避免安装被篡改的软件包。

---

七、结语：信任，是开源世界最贵的资产

xz-utils 事件最深刻的教训，不是”后门技术有多高深”，而是：

开源世界的根基是”信任”，而信任，恰恰是最容易被耐心的攻击者所渗透的东西。

一个匿名者，用三年时间、几个傀儡账号、几段”无害”的代码，就几乎瘫痪了全球 Linux 的信任链。这提醒我们：在供应链安全面前，没有人能置身事外——因为你的系统里，可能就运行着某个”关键却无人守护”的开源组件。

幸运的是，这次是一位工程师的 0.5 秒敏感，救了整个互联网。但下一次，未必还有这样的运气。

我们能做的，是从现在开始，认真对待每一个”看似不重要”的依赖、每一个”看似正常”的性能异常、每一个”看似热心”的陌生贡献者。

---

检测建议：与本站技术系列的联动

本文涉及的供应链与社工技术，本站已有对应的深度内容，可配合阅读：

本文技术点	延伸阅读
供应链投毒	《APT41：当”国家间谍”与”网络黑产”合二为一》《REvil 的 Kaseya 供应链》
社工与身份伪装	《Charming Kitten：伊朗”魅惑小猫”》
免杀与后门技术	免杀技术系列、《Mistic 后门 BOF 动态扩展》
黑客组织 APT 分析	Lazarus / LockBit 系列

---

参考资料

• CVE-2024-3094 官方描述与各发行版安全公告（Debian、Fedora、Red Hat 等）
• Andres Freund 在 oss-security 邮件列表的原始披露
• 关于”Jia Tan”社工渗透过程的公开复盘分析
• Openwall / oss-security 关于 xz 后门的技术分析

---

本文基于公开资料整理撰写，仅供网络安全研究与教育目的使用，不构成任何安全或法律建议。

---

相关文章

本文是「供应链攻击」系列的一员：

• 《Log4Shell：一次震动全球 Java 生态的”完美漏洞”》 —— 开源生态高危漏洞的另一个典型
• 《SolarWinds 事件复盘：一场潜伏九个月、横跨全球的”供应链核爆”》 —— 商业软件供应链投毒
• 《NPM/PyPI 供应链投毒：从依赖劫持到 typosquatting，开源依赖的隐形风险》 —— 开源依赖生态的投毒手法
• 《SSH 安全全景：从弱口令爆破到供应链劫持》 —— 供应链劫持视角下的 SSH 风险

---