Security

Postmortem: 关于 xzutil 后门事件的一些事后复盘

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

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

新的 arc4random_uniform 实现

本月初， Robert Clausecker 替换了 FreeBSD 的 arc4random_uniform(3)。

arc4random_uniform(3) 是 arc4random(3) 之上封装的一个生成一个较小范围伪随机数的函数。 arc4random(3) 采用密码学安全的伪随机数生成一个在 32-bit 范围，即 $[0,\ 2^{32}-1]$ 内均匀分布的伪随机整数， 此处的随机分布是依靠对称加密算法（目前采用的是 Chacha20）中用于实现加密的伪随机置换（Pseudorandom Permutation）来保证的。

PSA: 如何给自己的信用记录上锁

根据洛杉矶时报报道，骇客可能窃取了全部美国人的社会安全号。

社会安全号码（Social Security Number, SSN）是依据 42 U.S.C. § 405(c)(2) 发给一部分美国纳税人（包括公民、永久居民，以及有工作许可的临时居住在美国的人员）的一个九位数字。 目前，这个号码是由社会保障署（Social Security Administration）发给这些纳税人的， 尽管社会安全号码的设计本意是帮助社会保障署区分这些纳税人的，但由于它是由联邦机构签发的终生不变的数字， 因此它成了事实上的美国全国身份证识别代码，并且在税务以及许多其他地方都有使用。

PostgreSQL 安全漏洞 CVE-2024-4317

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

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 运行即可。

postfix 的 SNI 支持与 gmail 的兼容问题

今天在家里的票务系统上修改某个票的状态（该操作会出发点一封邮件）时， 我正好另一个窗口开着邮件服务器的日志，观察到一些奇怪的现象：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for 
  gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: self-signed certificate
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
  to gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
  (2048 bits) server-digest SHA256
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
  gmail-smtp-in.l.google.com[142.250.142.26]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
  to gmail-smtp-in.l.google.com[142.250.142.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
  (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
  alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
  to alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
  (2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
  alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: self-signed certificate
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established to
  alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
  (2048 bits) server-digest SHA256
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Verified TLS connection established to
  alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA
  (prime256v1) server-digest SHA256
Mar 19 20:17:15 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: to=<XXXXXXX@gmail.com>,
  relay=alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25, delay=2.8,
  delays=0.06/0.1/2/0.66, dsn=2.0.0, status=sent (250 2.0.0 OK  XXXXXXXXXX
  XXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.XX - gsmtp)

SMTP Smuggling

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

用 rspamd 来实现反垃圾邮件

我搞邮件服务器有二十多年了，最开始是在学校做社团的邮件服务， 后来有几年和 老房东 在某领先网络媒体公司做了多年针对公众提供的邮件服务，因此前同事群的名字也是「老邮条」。 我个人的域名是2002年注册的，自从那时起我就一直在自己运行邮件服务。

在过去二十年中的大部分时间，我采用的是 amavisd-new， 与直接使用 SpamAssassin 相比， 它还增加了病毒扫描等一系列功能和 milter 接口，这让它与 MTA 更容易集成。

关于 Google Workspace 的 SPF / DMARC 设置

这里简单记一笔。我有一个域名使用的是 Google Workspace 的邮件服务。 昨天，一位用户使用该域名向中国的 QQ 邮箱用户发送邮件时被退回了。

退信中给出的线索是：

550 DMARC check failed [XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
IP: 2607:f8b0:4864:20::112b]. https://service.mail.qq.com/detail/124/61.

腾讯给出的那个链接是一篇关于 DMARC 如何配置的文章。 从上下文来看，应该是由于腾讯的服务器认为 Google Workspace 的 IP 地址不在允许发信的范围内。

退信确实是 Google Workspace 的邮件服务生成的，数据来源是和对方(腾讯) MX 之间的 SMTP 会话。

我的这个域名确实启用了 DMARC。我的DMARC记录 (域名下的 _dmarc TXT 记录) 设置如下：

v=DMARC1; p=reject; rua=mailto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX@dmarc-reports.cloudflare.net;
pct=100; adkim=s; aspf=s

此配置要求对方检查 DKIM 和 SPF，并拒绝不匹配的邮件。

其 SPF 记录 (域名的 @ 的 TXT 记录) 设置如下。这是 Google 官方文档中推荐的设置：

v=spf1 include:_spf.google.com -all

主要的区别是，我使用的是 -all，即拒绝 SPF 不匹配的邮件，而不是更为常见的、表示即使发现 SPF 不匹配，也仅仅做标记但允许接收的 ~all。

这里需要说一下背景：在 2004 年左右，一些业内人士认为应该推荐采用 ~all 而不是 -all，因为当时许多大型邮件系统的架构中存在多层邮件服务器分别进行不同的过滤处理， 而在 SMTP 会话阶段直接回一个永久性拒绝 (5XX) 代码可能会让一些不适任的邮件系统管理员如此配置的邮件系统将一些伪造了来源的邮件退到不希望的地方。 我并不赞同这样的观点。事实上，在会话阶段进行退信要比在收件方服务器上生成退信并将退信退给发件人或对方域名的 postmaster 要更好： 对于垃圾邮件的发送者，这意味着他们的邮件服务器会立即知道自己的行为被直接地丑拒， 接收方明确告知他们吞下垃圾邮件，而不是继续发送。对于正常的邮件服务器， 这意味着发件人可以立即收到退信从而找到自己的邮件系统管理员，而不是告诉收件人去翻垃圾箱看看是否有自己的邮件。 另一方面，回应永久性拒绝并不妨碍收件服务器对邮件内容进行进一步分析：它完全可以在 DATA 阶段结束时再回拒绝，从而将邮件完整地接收下来但不递给收件人。

当然，历史无法假设，并已经无数次地证明人类根本不配拥有美好的事物。

DomainKey 记录 (域名下的 google._domainkey TXT 记录) 由于与此问题无关，故在此处略去。

该域名启用了 DNSSEC。

采用 Ed25519 的 DKIM 签名

Ed25519 是一种高性能的公钥签名系统。和 RSA 相比， 同等强度的 Ed25519 的密钥长度要比 RSA 短很多，此外，软件实现的 Ed25519 的验证速度也比同等强度的 RSA 快很多。

尽管早在2018年 RFC 8463 Section 5 就已经将 RFC 6376 Section 3.3 修正为要求验证者必须支持 Ed25519 验证，然而时至今日主要的邮件服务提供商中， 包括 Google 的 Gmail 和 Microsoft 的 Outlook.com 以及 Apple 的 iCloud 都还不支持验证 Ed25519 DKIM 签名。ProtonMail 支持 Ed25519 的 DKIM 签名，但它并不使用 Ed25519 签名向外发出的邮件。

在本地架设根 DNS 的镜像

目的

在本地的局域网上建立 DNS 解析服务可以显著地改善 DNS 的安全性：所有的 DNS 查询将由可以信任的本地 DNS 解析服务进行验证， 而不是简单地相信一台不受控的远程服务器通过 UDP 提供的应答。因此，这些年来我自己的网络包括机房的网络都是自己运行一组 DNS 解析服务的。

• 下一页 →