Security

前几天我收到了一封措辞颇为客气的邮件：

Subject: Urgent Link Update – Prevent Misinformation

Dear partner delphij.net,

It has come to our attention that your site still contains a hyperlink to our former domain. This domain is no longer managed by our organization and now carries content that could be misconstrued as affiliated with us, potentially leading to misinformation.

Please replace this outdated link with our official and active website:

Old URL: futureofflight. org
New URL: futureofflight.en-html.org

The old link appears in: https://blog.delphij.net/posts/2009/09/-/

We appreciate your cooperation in promptly correcting this matter to maintain editorial accuracy.

Best regards,

Grace Condie, Web Content Coordinator

Future of Flight Team

---

This email and its contents are confidential and intended only for the recipient. If you are not the intended recipient, please do not share or use this information and notify the sender.

大意是说，我多年前（2009年）一篇记录去华盛顿州旅行的文章里，链接到了波音飞行博物馆当时使用的域名 futureofflight.org。邮件称该域名已不再由他们维护，并建议我将其替换为「官方且活跃」的所谓新域名：futureofflight.en-html.org。

如你所见，对方还十分贴心地在旧域名中添加了空格，防止我误触；甚至还指出了有问题的 URL，行文措辞也显得颇为得体客气。

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

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

在上一家公司的时候曾经有很多关于 cron(8) 的想法，但一直没有付诸实施，很多东西放在本地慢慢生锈了。

去年年底的时候我开始着手去修了一些 cron(8) 的 bug，其中包括为 cron 之前不够完整的 PAM 支持进行了改进。

背景：PAM

Pluggable Authentication Module (PAM) 为一系列身份验证相关的操作提供了一组通用的接口。在没有 PAM 之前，应用程序需要实现大量重复的代码来完成类似的操作，例如要求用户输入密码并进行验证等。这么做的问题在于缺乏灵活性，例如，管理员可能希望将用户数据保存到 LDAP 目录中，或是使用指纹等新式验证方式。PAM 使这些相关操作可以通过插件来完成，应用程序不再需要关心「如何验证用户身份」（用户名、密码等等是不是正确），而只需要向 PAM 询问「该用户的身份是否合法？」即可。这层抽象简化了应用程序开发者的工作，并且赋予了系统管理员更大的灵活性。

PAM 将系统的认证工作分成了四组基本操作：

• auth：验证用户身份（比如检查密码）。
• account：检查账户是否有效（比如是否过期、是否允许在此时间登录）。
• password：用于修改密码。
• session：会话管理，即用户「进门前」和「出门后」需要进行的环境搭建或清理工作。这是本次更新的核心。

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

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

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

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

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

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 协议的攻击手法，现在的年轻人真是蛮厉害的。

软件项目中，实现同一功能的源代码只保留一份是一项十分重要的最佳实践，这种做法可以带来许多显而易见的好处：

1. 简化依赖关系管理。 对于 C/C++ 项目来说，如果同一个函数库有不同的版本，意味着必须设法确保其中不包含同一符号的多个变体。
2. 减少技术债的积累。 只保留一个版本意味着参与项目的所有开发者都使用最新版本的库，或是从一个接近最新版本的库升级到最新版本，这要比把技术债留给后人去解决要容易许多。尽管升级时需要考虑的问题会更多一些，但这也意味着更好的一致性。只留一份版本意味着在升级时必须通盘考虑全局的影响，配合持续集成测试的使用，这也会带来更好的代码品质，并让整个团队能够更快地进行迭代。
3. 节省各类存储占用。
4. 改善整体安全性。问题只需在一处进行修正。

2009年的时候 kmacy@ 做了 一些初步的工作，但后续没有继续推进。这之后 我 考虑重新把这个事给做掉，但苦于平时比较忙因此未能如愿。最终， Yoshihiro Ota完成了大部分的工作。

这里简单记一笔。我有一个域名使用的是 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 是一种高性能的公钥签名系统。和 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 签名向外发出的邮件。