说明：这是关于北美时间2024年3月28日披露的 xzutil 后门事件的一些事后复盘。 关于漏洞本身的一些更为详细的背景和细节以及其发现过程， 在 Bryan Cantrill 和 Andres Freund 的这次 访谈 中有相当详尽的说明。由于漏洞并非我们发现，在此便不再赘述漏洞本身的细节。
值得庆幸的是，我们有足够的理由认为这次事件中 FreeBSD 并没有受到影响，但这里有相当大的运气的成分， 整体而言，我们的流程并非无懈可击，因此有必要进行一些总结。
背景
自称叫「Jia Tan」的开发者花费了两年的时间逐渐取得了上游社区的信任，并最终成为了 xzutils 的维护者。
攻击者在 2024 年 2 月 23 日在源代码中的一处二进制文件中放置了后门，并随后发布了 xz 5.6.0。 攻击者发布的源代码包中，以巧妙地方式增加了激活后门的脚本。值得注意的是，这些脚本从未进入过 xzutils 的 Git 代码库，因此躲过了包括 FreeBSD 在内的开发者进行的日常代码审计（值得说明的是，由于这些脚本通常是自动生成的， 体积庞大且随 autoconf 等工具的版本变化很大，因此其内容审计难度较大。比较稳妥的做法是从人类易读的 autoconf 文件中重新生成这些脚本）。
由于后门代码最初版本的 bug，攻击者在接下来的两周时间进一步对后门进行了修补以增加其发现的难度。
主要的 Linux 发行版，包括 Debian 和 RedHat，均在其开发版本中跟进了这些变动。 由于 systemd 的插件设计，这些变动导致后门被插入到了这些 Linux 发行版中的 sshd 服务中。 由于后门引入了一系列计算密集的代码，人们逐渐注意到了一些奇怪的性能问题。
最终，PostgreSQL 开发者，就职于微软公司的 Andres Freund 在经过了一段时间的性能追踪之后， 正式确认了 xzutils 后门的存在，并立即通知了主流发行版的安全团队。
我本人也在第一时间收到了通知。当时是太平洋时间的中午，我没有携带解密所需的密钥， 但由于这一讨论相当热烈，加上邮件标题并不加密，因此我大概知道了发生了什么事。
FreeBSD 中的 xzutils
xzutils 是一款压缩工具，由于其压缩比高、解压缩性能好，因此 FreeBSD 在 2010 年就在 base system 中加入了 xzutils。 FreeBSD 在 2024 年 3 月 9 日将 xz 5.6.0 合并到了开发主线。
FreeBSD 的 base system 中第三方软件的维护者有责任追踪这些第三方软件的开发， 这包括在平时跟进这些第三方软件的代码变动，也包括在引入代码时做最后一次的代码审计。
我是 FreeBSD 中 xzutils 的维护者，因此我平时会关注上游的改动，并查看这些 commit 引入的变动。 不过，在引入代码时，我往往会使用上游签名的 tarball，和 git 版本比较一下，而不是从上游的 git 直接合并代码。
供应链攻击
前面提到，自称「Jia Tan」的人或团队花了两年时间逐步获取了信任，并成为了 xzutils 的维护者。 这意味着此人签名了相关的 tarball。通过在联编脚本中植入一个二进制文件后门， 这次供应链攻击使得大部分 Linux 发行版在打包时会引入这个后门，该后门会将 RSA_public_decrypt 替换为攻击者的入口，允许链接了liblzma的使用该函数的程序运行任意代码。
由于 FreeBSD 引入第三方代码时会重写整个 build 部分，并且将用例部分直接删除， 因此其实 FreeBSD 并未受到此问题的影响。 不过，由于 xzutils 导致了一系列公关危机，出于谨慎起见我们于 2024 年 4 月 4 日将版本回退到了 5.4.5 版本。2024 年 6 月，我们重新引入了经过更多人审计之后发布的 xz 5.6.2 版本。
暴露的问题和后续补救
尽管我们做了包括比较 tarball 内容和 git 内容、逐项审计代码这些操作，但这次供应链攻击还是让我出了一身冷汗， 其原因在于我之前会以自己用户的身份而不是在虚拟机中的非特权用户（或者说一个沙箱环境）运行联编所需的脚本。 相对来说，供应链攻击其实首先是针对我们这些维护者的攻击，尽管攻击者需要考虑我们这些人所用的各种千奇百怪的环境， 但攻克了这些人之后进行更进一步的供应链攻击将变得更加顺利。
为此，我 更新 了 FreeBSD 的开发流程，并将这部分（在隔离环境中运行任何下载的代码） 列入了新的最佳实践。
本次供应链攻击尽管对 FreeBSD 并未造成任何伤害，但留下的教训是相当深刻的。