在一个普通的周五早晨（2024年3月29日），我在浏览黑客新闻时，看到一篇快速升温的文章——“xz/liblzma上游代码后门导致SSH服务器被入侵”。文章讲述了令人不安的故事：一名叫Andres Freund的工程师正在调查Postgres性能问题，他发现SSH的CPU使用率异常升高。
经过调查，Andres发现问题源于一个名为xz/liblzma的依赖库中的注入代码。他进一步揭示了恶意代码的执行条件以及它如何在SSH认证过程中的RSA部分发挥作用。这一发现拉响了警报，Andres联系了多个组织和个人来验证他的发现，结果证实了他的担忧。
过去48小时里，情况变得非常紧张。起初，我对xz是什么一知半解，只记得它是一个压缩库。xz实际上比我想象的要复杂一些，但我不明白它怎么会和SSH扯上关系，因为openssh的依赖列表中并没有列出xz。我下载了openssh的Debian包并搜索“xz”，发现了一些有趣的信息。
原来，Debian包在某个时间点移除了使用xz压缩的dh_builddeb覆盖，并在后续版本中重新启用。这意味着Debian可能为SSH添加了一个额外的依赖以引入xz包。得益于Debian对上游软件的补丁处理方式，很容易找到这些变化。
了解到依赖链后，我想了解恶意软件是如何注入的以及由谁注入。Andres指出，一个看似无害的提交引入了恶意代码，该提交增加了新的测试文件。然而，任何工程师看到这个提交都会觉得奇怪，因为二进制文件的添加并没有对应的代码引用。
故事变得可疑起来，恶意软件引入后并未立即生效，导致作者迅速修复了一些问题，例如GCC错误报告、Valgrind问题等。这引起了怀疑，特别是考虑到一些修复行为。有人在讨论中指出，这些行为可能是合理的，但也可能存在问题。
随着调查的深入，我发现xz在systemd中也有使用，这解释了SSH如何受到影响。同时，OSS-Fuzz项目（一个持续模糊测试开源软件的平台）发现了近万个漏洞并修复了超过3.6万个错误。这个工具检测到了xz的构建失败，而我们的疑似恶意作者通过禁用某些功能解决了这个问题，这让人感到非常奇怪。
进一步研究发现，一个名为Jia Tan的人成为了xz项目的主维护者。回溯邮件列表，发现Jia Tan似乎是在2022年通过帮助解决项目问题逐渐获得了维护者的角色。然而，一些用户的行为显得可疑，他们似乎在推动原维护者分担责任。最后，原维护者Larhzu表示Jia Tan可能会扮演更重要的角色。
Jia Tan后来尝试将恶意代码合并到操作系统发行版中，但被Debian社区成员注意到并质疑。最终，恶意代码没有进入测试分支，仅停留在不稳定分支。此外，Jia Tan还试图将恶意版本推送到Ubuntu，但被发现。
Jia Tan的GitHub账户创建于2021年初，其早期的贡献包括一个可能引入更严重漏洞的补丁，尽管社区随后修复了这个问题。Jia Tan的其他一些提交也被迅速撤销，这让人对他们的动机产生了怀疑。
总的来说，这个故事揭示了一名潜在的恶意贡献者如何在开源社区中获得信任，然后在xz项目中引入后门。这提醒我们，对开源软件的依赖链进行深入理解，并保持警惕，尤其是在关键软件的依赖项中。
