XZ恶意代码潜伏三年，差点引发核末日？后门投毒黑客身份成谜

---

  新智元报道  

整个周末，开源软件xz被植入后门事件，引发了安全界的轩然大波。

研究人员惊恐地发现，在包括Red Hat和Debian在内的多个广泛使用的Linux版本中，一款压缩工具被悄悄植入了恶意代码！

微软的安全研究员Andres Freund首次报告了这件事。

他发现，在这款名为xz Utils的工具的5.6.0和5.6.1版本中，都含有恶意代码。

而且，这段恶意代码极其复杂难解。

扒着扒着人们发现，这段代码是由一位名为Jia Tan的用户（JiaT75），通过四次代码变更（也即在GitHub上「提交」）的方式，植入到了Tukaani项目中。

这样，攻击者即使没有有效账号，也可以直接从SSHD访问系统了。

（SSHD是一个关键的二进制文件，负责SSH连接的工作。）

目前，GitHub已经禁用XZ Utils代码库，且还未收到漏洞被利用的报告

好在，这个后门已经及时被发现了。目前GitHub已经以违反服务条款为由，禁用了Tukaani项目维护的XZ Utils代码库。

然而可怕的是，如果这个后门的漏洞很巧妙，技术很高超，那么xz被广泛引入各Linux发行版后，这些Linux系统就会轻易被入侵！

这件事情可能导致的可怕后果，让安全社区对此掀起了经久不息的讨论。

好在证据显示，这些软件包只存在于Fedora 41和Fedora Rawhide中，并不影响Red Hat Enterprise Linux (RHEL)、Debian Stable、Amazon Linux以及SUSE Linux Enterprise和Leap等主流Linux版本。

但Red Hat和Debian已经报告称，最近发布的测试版中的确使用了这些被植入后门的版本，特别是在Fedora Rawhide和Debian的测试、不稳定及实验版本中。

同样，Arch Linux的一个稳定版本也受到了影响，不过，该版本也并未应用于实际生产系统中。

另外还有一些读者报告称，macOS的HomeBrew包管理器中包含的多个应用，都依赖于被植入后门的5.6.1版本xz Utils。目前，HomeBrew已经将该工具回滚至5.4.6版本。

安全公司Analygence的高级漏洞分析师Will Dormann表示，「这个问题实际上并没有对现实世界造成影响」。

但这主要是因为恶意行为者疏忽了，导致问题被发现的时机很早。就如同上文所提，如果后门没被及时发现，后果将是灾难性的。

既然事情解决了，那么问题的焦点就集中在了——Jia Tan究竟是谁？

这位Jia Tan，是xz Utils项目的两位主要开发者之一，对该项目贡献良多。

Freund其报告中指出，「考虑到这几周内的活动情况，这位提交者要么是直接涉及，要么其系统遭受了严重的安全威胁。」

不幸的是，种种迹象表明，后一种可能性似乎并不大。

所以，这次xz被植入后门事件，很可能就是Jia Tan的主观恶意行为。

上周四，有人冒用了这位开发者的名字，在Ubuntu的开发者社区中请求将含后门的5.6.1版本纳入正式发布，理由是它修复了一个导致Valgrind工具出错的问题。

还有人发现，近几周这位开发者也向他们提出了类似的请求，希望在Fedora 40的测试版本中使用这个带有后门的工具版本。

「我们甚至还帮助他解决了Valgrind的问题（而现在看来，这个问题正是由他加入的后门引起的），」Ubuntu的维护人员说。

「他已经在xz项目中工作了两年，添加了各种各样的测试文件，鉴于这种复杂的操作，我们对xz的早期版本也持怀疑态度，直到后来，它们被证明是安全的。」

简单来说，CVE-2024-3094引入的这个后门，是为了在受害者的OpenSSH服务器（SSHD）中注入恶意代码，从而让远程攻击者（持有特定私钥）能够通过SSH发送任意代码，并在认证步骤之前执行，进而有效控制受害者的整台机器。

尽管具体的内容仍在分析当中，但初步分析表明，它的设计相当复杂：

• 后门代码被注入到OpenSSH服务器（sshd进程），因为liblzma（含有恶意代码）是某些OpenSSH版本的依赖项。

• 后门劫持了RSA_public_decrypt函数，这个函数原本用于验证RSA签名。

• 恶意代码会检查RSA结构中传入的公共模数（「N」值），这个模数完全受到攻击者控制。

• 恶意代码使用硬编码的密钥（采用ChaCha20对称加密算法）对「N」值进行解密。

• 解密后的数据通过Ed448椭圆曲线签名算法进行有效性验证。由于这是一种非对称签名算法，后门只包含了公钥，这意味着只有攻击者能够为后门生成有效载荷。此外，这个签名与主机的公钥绑定，因此一个主机上的有效签名不能在其他主机上使用。

• 如果数据有效，该有效载荷将以shell命令的形式被执行。

• 如果数据无效（有效载荷格式不正确或签名无效），则会透明地恢复到RSA_public_decrypt的原始实现。这意味着，除了攻击者之外，是无法通过网络发现易受攻击的机器的。

这次最令人印象深刻的，是攻击者超乎寻常的耐心和决心。

攻击者花费了两年多的时间，通过参与各种开源软件项目并提交代码，逐步建立起作为一个可信任维护者的形象，以此来避免被发现。

2021年，一个名为Jia Tan（GitHub用户名：JiaT75）的用户创建了GitHub账户，并开始为多个项目做出贡献。

在那一年，Jia Tan共提交了546次代码，其中对libarchive项目的一次提交尤其引起了人们的关注。

2022年2月6日，Jia Tan在XZ项目中做出了他的第一次正式提交，这次提交增加了对LZMA和LZMA2编码器的参数验证功能。

2023年6月27日至28日，Jia Tan对XZ Utils项目进行了一系列关键的更改，从而为后续的攻击做好了准备。

特别是，项目中的一个文件crc64_fast.c，新增了对一种名为ifunc的技术的支持。

根据安全研究员Andres Freund的分析，引入的这种ifunc技术可能是潜在后门功能的一部分，显示了攻击者可能利用的一种手段。

此外，值得注意的是，这个重要更新是由项目的原始维护人Lasse Collin引入的，并且他特别提到了另一位贡献者Hans Jansen对这一更新的贡献。

2023年7月8日，JiaT75在oss-fuzz项目中提交了一个请求，该项目负责对XZ等多个开源软件项目进行自动错误检测。这个请求实际上关闭了一种特定的错误检测方式，从而防止oss-fuzz发现XZ项目中潜藏的恶意代码。

2024年2月15日，JiaT75通过修改XZ项目的配置文件，加入了一个规则来忽略特定的脚本文件build-to-host.m4。

很快，这个脚本就被包含在了项目的正式发布版本中——它会在构建过程中执行，并植入一段负责在受害者电脑上安装后门的恶意代码。

2024年2月23日，JiaT75在XZ项目的测试文件夹中加入了两个含有隐藏后门的测试文件。

2024年2月24日，JiaT75发布了包含恶意脚本文件的新版本5.6.0，也就是说任何使用了这个版本及以后版本的XZ都存在安全风险。

2024年2月27日，这个带有安全隐患的版本被Fedora采纳。

2024年3月9日，JiaT75更新了后门程序，发布了版本5.6.1，Fedora同样更新了这个版本。

2024年3月29日，安全研究员Andres Freund在oss-security邮件列表上公布了他对XZ项目中发现的恶意行为的详细分析。

虽然恶意代码仅在XZ项目中被检测到，但攻击者账户的其他代码贡献目前也在调查中。

截至今日，一些项目已经被发现添加了可疑代码：

libarchive

2021年，JiaT75向libarchive代码库提交了一个名为「在使用bsdtar解压时添加错误提示文本」的合并请求，乍看之下似乎没什么问题。

但仔细一看，这个合并请求中的代码把原本安全的函数safe_fprintf()换成了更危险的fprintf()函数，这一改动可能会导致字符逃逸的安全漏洞。

oss-fuzz

2023年初，JiaT75把XZ项目在Google的oss-fuzz工具上注册的主邮箱改为了他个人的Gmail邮箱。

这一行为似乎暗示，他们想要第一时间接收到XZ项目中发现的漏洞报告，以此来及时知晓自己的恶意操作被揭露的情况。

2023年末，他们提交了一个新的合并请求（Pull Request），目的是在XZ项目的fuzzer配置中禁用「间接函数支持（Indirect function support）」。

这一操作似乎可以防止被fuzzer探测到，从而为在XZ项目中植入的后门做好铺垫。