Vulnerability

今年，软件安全领域出现了一个新的变化：AI 辅助下的漏洞发掘，正在迎来真正的井喷式增长。

随着大模型对复杂代码理解能力的跃升，安全研究人员手中的工具获得了质的飞跃。这股浪潮最直观的表现，便是我们作为开源代码维护者，在收件箱里收到的大量问题报告和邮件。

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

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

之前没有特别注意这个漏洞，这里稍微记一笔。

PostgreSQL 包含一系列系统视图，这些系统视图可以用来查询系统表。由于 pg_stats_ext 和 pg_stats_ext_exprs 这两个视图在 PostgreSQL 14-16 的 16.3、15.7 和 14.12 之前的版本中缺少了必要的访问控制，因此未经授权的用户将可以通过这些视图访问其他用户通过 CREATE STATISTICS 创建的一系列统计数据，而这些数据可能会揭示这些未经授权的用户原本没有权限访问的数据，或是函数的执行结果。

PostgreSQL 在 16.3、15.7 和 14.12 中修正了这一问题，但这仅限于新安装的情况。对于已经安装好的正在运行的数据库，管理员还必须重建这两个系统视图以收紧权限（加入了 WITH (security_barrier) 以及 WHERE 子句来限制访问）。修正脚本位于源代码的 src/backend/catalog/fix-CVE-2024-4317.sql (对于 FreeBSD pkg 用户，这些修正脚本会安装到 /usr/local/share/postgresql/fix-CVE-2024-4317.sql)，使用 psql 运行即可。

最近没怎么关注安全方面的进展，结果错过了去年年底披露的 SMTP Smuggling。这是 Timo Longin 发现的一个全新的针对 SMTP 协议的攻击手法，现在的年轻人真是蛮厉害的。

今天早上4点多就爬起来准备发安全公告（友商约的是早上5点发），一刷，OpenSSL官方已经正式发表了（时间大约是4点30），于是立即开始相关手续，commit修正，发公告，通知CERT，这些不表。

这次 Heartbleed 安全漏洞之后，阿里巴巴集团的多个产品均迅速修复了漏洞（好事），但事后的公关处理做的却有待改进。

我在微博上看到有人转发 阿里安全 在4月9日13:01发表的一篇微博，内容如下：

关于OpenSSL某些版本存在基于基础协议的通用漏洞，阿里各网站已经在第一时间进行了修复处理，目前已经处理完毕，包括淘宝、天猫、支付宝等各大网站都确认可以放心使用。

紧接着， 支付宝 转发了 这条微博：

大家可以放心了！

我并不是阿里巴巴/支付宝的客户，不过看到有人转发这条消息，我半开玩笑地 回了一句：

冲这句「大家可以放心了」就没法放心了……

今天(2014/01/14)发了4个安全公告和2个勘误公告，其中 FreeBSD-SA-14:02.ntpd 是针对 NTP 的这种攻击的因应措施。

攻击的原理是通过发送一个小包（GET_MONLIST），得到大体积的回应。而由于 NTP 使用了 UDP 协议，因此攻击者可以伪造源 IP，从而，通过较小的流量代价，即可利用其他服务器作为杠杆来攻击受害者。

今天发现一台国内的机器流量异常，检查发现这台机器上运行的 DNS 缓存服务被人用作了攻击的放大杠杆，这里简单记一下。

发现流量异常，首先当然是检查服务器上的 TCP 会话，发现了一些不太正常的东西，关闭之后流量减少，但仍然没有回到正常水平。

于是听包。这一听发现一大片：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

07:39:53.271744 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271772 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271784 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271792 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.274225 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274252 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274262 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274270 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.291822 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291850 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291860 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291869 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291877 IP 92.XX.XX.148.56278 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)

计时攻击是一种通过观测由于某些操作时泄露出来的时间信息来获取更多信息的攻击。由于设计和实现的不同，攻击者能够通过计时得到的信息也会不一样。简而言之，作为安全系统的设计者，必须对可能泄露信息的各种渠道有充分的了解，并针对它们采取因应措施。

这次休假前头一天晚上收到了 ISC 发来的安全公告 CVE-2011-1910。我起草完 FreeBSD 安全公告 FreeBSD-SA-11:02.bind.asc 之后就去休假了，这里补上这个漏洞的说明。

无论你是否使用 DNSsec，只要用 BIND 9.x 来做 DNS 缓存解析服务（而不仅仅做Authoritive DNS服务），就有可能受到这个漏洞的影响。而攻击的方法也相当简单，攻击者只要建立一个 DNS 域，令在回应域名不存在的同时发回一个大的 RRSIG RRset，即可触发 BIND 的某处断言令其退出。