Postmortem

说明：这是关于北美时间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 后门的存在，并立即通知了主流发行版的安全团队。

我本人也在第一时间收到了通知。当时是太平洋时间的中午，我没有携带解密所需的密钥，但由于这一讨论相当热烈，加上邮件标题并不加密，因此我大概知道了发生了什么事。

12月1日，FreeBSD 发布了 FreeBSD-EN-23:16.openzfs，用于修正近期发现的 ZFS 数据损坏问题。这个问题是由 Rob Norris 最终修正的，这里记一笔。

摘要

事故影响

由于 UPS 测试触发了系统停机，导致 delphij.net 部分服务停止了约40分钟。服务从 2023-01-16 15:46:20 开始受到影响，至 16:26:55 完全恢复。如果服务未能及时修复，潜在地将会进一步影响包括权威DNS（有多个独立的冗余，但依赖于持续的数据更新）在内的一些其他关键服务。

问题根源

在测试时对于 CyberPower UPS 测试特性的认识不足导致电池电量消耗至临界值，由于对 nut 的配置未考虑这种情况直接将服务器关闭，这使得必须亲自到机房才能完成服务的恢复。

今天和 Henry Hu 聊起 iichid 已经进了 FreeBSD 的主线，想起自己之前鼠标啥的还是都在用 sysmouse，觉得既然来都来了就索性都改成 evdev 的输入设备算了？改了 /boot/loader.conf 并增加了下列设置：

iichid_load="YES"
usbhid_load="YES"
hms_load="YES"
hw.usb.usbhid.enable="1"    # 防止uhid(4)接管

重启。等等，一闪而过的那是什么？

ntpd is not allowed to log in on /dev/console

这是我加入 FreeBSD Release Engineering Team (re@) 之后，我们发布的第一个主要（X.0）版本。

这个版本对整个系统进行了大量的改进。其中的重要变化包括在基本系统中用 clang 取代了 gcc（所有 Tier-1平台）、新增了 unbound（用于取代BIND的部分功能，后者十分复杂，且支持计划经常与 FreeBSD 的发生冲突）、基本系统中提供了转码API iconv(3) （我在2010年指导的 Summer of Code项目）、使用了 PkgNG 包管理工具、BHyVe虚拟机、对于虚拟化支持的大幅改进（virtio(4)以及 Hyper-V支持）、ZFS新增了TRIM支持、ZFS的LZ4完整支持（我在去年新增的功能），等等。

我回国之前， FreeBSD 安全团队内部正在准备一项重要的安全公告，不过这次不是由于 FreeBSD 的代码本身，而是由于 FreeBSD 项目集群中的一部分受到了入侵。这份公告后来于 11 月 17 日正式 发表。

长久不做 SA，所以有些事情变得没有以前那么敏感。昨天终于还是出事了，不过幸亏不是商业系统，如果是的话，我觉得绝对够得上是重大事故。记一笔，留个教训。

📜 OpenLDAP 现已转为使用 lmdb。

今天帮陈总研究一个奇怪的问题的时候误操作导致机器停止ssh响应，遂请机房重启。由于机房做的是power cycle，导致部分数据丢失。先前在配置OpenLDAP时，忘记在其中配置checkpoint，另外也没有对这台机器的LDAP进行备份，因此只好尝试从现有的数据库中恢复。冗余不做，日子甭过；备份不做，十恶不赦！

记录一下修复过程。

第一件事是把出问题的数据库做一份备份：rsync -av /var/db/openldap-data/ /var/db/openldap-data.old/

接着尝试slapcat。出现下面的错误：

1
2
3
4
5
6

bdb(dc=********.com): file id2entry.bdb has LSN 1/1476384, past end of log at 1/374639
bdb(dc=********.com): Commonly caused by moving a database from one database environment
bdb(dc=********.com): to another without clearing the database LSNs, or by removing all of
bdb(dc=********.com): the log files from a database environment
bdb(dc=********.com): /var/db/openldap-data/id2entry.bdb: unexpected file type or format
bdb_db_open: database "dc=********.com": db_open(/var/db/openldap-data/id2entry.bdb) failed: Invalid argument (22).

尝试使用BerkeleyDB的修复工具修复：

1
2
3
4
5

# db_recover-4.6 -vvf
Finding last valid log LSN: file: 1 offset 374639
recovery 0% completeRecovery starting from [1][374527]
recovery 67% completeRecovery complete at Tue Jul 13 16:41:59 2010
Maximum transaction ID 800000c0 Recovery checkpoint [1][374639]

slapcat发现问题依旧。搜索Google发现答案基本上都是从备份中恢复，看了一下Oracle的网站，关于这类问题也没有很好的办法。尝试将bdb文件dump出来再load回去：

1
2
3
4
5

db_recover-4.6 -vvf
db_dump-4.6 id2entry.bdb > /tmp/id2entry.dump
rm id2entry.bdb
db_load-4.6 id2entry.bdb < ~/id2entry.dump
db_recover-4.6 -vvf

再次slapcat，发现对另一文件报错，用类似的方法修补之后，slapcat成功。

将slapcat的输出导出到一个文件中： slapcat > /tmp/my.ldif

然后，删除OpenLDAP数据目录：rm /var/db/openldap-data/_* /var/db/openldap-data/[a-z]*

最后，重新使用导出的ldif文件恢复：slapadd -l /tmp/my.ldif。

至此，恢复完成。

由于磁盘故障，ftp.freebsdchina.org 暂时无法提供服务了(初步估计是panic掉了)。更头疼的是，由于连续5年运行没有出过什么严重问题，这台机器在机房的位置恐怕也不太好找了。

Peter早上发信说这台机器(committer转信以及邮件列表等)上许多芯片烧掉了，还有一些芯片上出现了穿孔并露出了硅片……不过他迅速地更换了硬件。由于FreeBSD.org使用了多个MX，因此这一故障并未导致邮件丢失。