一

2024 年 3 月 28 日下午，Andres Freund 在 Microsoft 总部一个办公桌上做着完全平常的事——给 PostgreSQL 数据库做性能基准测试。Freund 是 Microsoft 的 principal engineer，长期是 PostgreSQL 上游核心开发者之一。他那天用的 OS 是 Debian Sid——Debian 的不稳定开发版，新代码先到这里测试。

测试结果不正常。SSH 登录耗时从他记忆中的大约 100ms 变成了大约 500ms。这种延迟在 SSH 这种系统级守护进程里是很奇怪的——SSH 应该几乎瞬间响应；500ms 几乎是网络延迟级别的。

如果是 99% 的程序员，他们会注意一下，重启一下机器，发现还是 500ms，然后耸耸肩，继续做正事。Freund 不是这种人。他长期做 PostgreSQL 性能工程，对“为什么这个东西比预期慢”有职业病般的好奇1。

他开始用 perf 工具看 SSH 进程的 CPU 占用。看到了一些让他困惑的 stack trace——大部分时间花在 liblzma 库里。这不正常。liblzma 是 xz Utils 这个压缩库的一部分，它的功能很基础：解压 .xz 格式文件。SSH 这种程序为什么会在 SSH 握手时花大量 CPU 在 liblzma 里？

Freund 又跑了一遍 Valgrind——一个内存调试工具。Valgrind 在 SSH 启动时报错，指向 liblzma 的某些内部函数。

到这里他开始觉得不对劲了。他花了“几周时间”（他后来在 Mastodon 发的复盘帖里说的）——一边正常工作，一边在业余时间挖这个 liblzma 异常2。最后他追踪到一个具体的事实：xz Utils 5.6.0 和 5.6.1 的 release tarball 里，有一段在 GitHub 源代码 repository 里看不到的恶意代码——它通过 build-to-host.m4 这个 autotools 配置脚本，在编译时把自己注入到 liblzma 二进制中3。

3 月 27 日（周三），Freund 联系了 Debian 安全团队（security@debian.org）。 3 月 28 日，他给 Linux distros 安全列表发了私下警报。 3 月 29 日上午，他在 oss-security 公开邮件列表发布完整报告。

接下来 24 小时是 Linux 世界的另一个 Log4Shell 时刻。Debian、Ubuntu、Fedora、Arch Linux 紧急回退 xz Utils 到 5.4.x 旧版本。Red Hat 发布紧急通告。CISA 发布最高级警报4。

但 xz 跟 Log4Shell 有一个关键不同。Log4Shell 是一个无意的 bug——Ralph Goers 2013 年加 JNDI lookup 功能时没意识到安全含义。xz 不是 bug。xz 是一个国家级行为者经过约三年的精心社会工程，逐步获得 xz Utils maintainer 权限，然后在 2024 年 2 月把后门嵌入到 5.6.0 release 的有意攻击。

要看清楚这件事的全部含义，我们需要从 2021 年 10 月那个不起眼的 commit 开始倒回去看。

二

2021 年 10 月 29 日，xz Utils GitHub 仓库收到一个 pull request，签名是 “Jia Tan” (GitHub username: JiaT75)5。

PR 内容是一个 .editorconfig 文件——一个非常无害的小改动，告诉编辑器用什么样的缩进风格、换行模式等。这种 PR 完全没有可疑性。任何开源项目都会收到大量这种小贡献。

xz Utils 当时的主维护者 Lasse Collin 看了一眼，合并。Jia Tan 第一次贡献。

接下来几个月，Jia Tan 陆续提交一些小改进——build reproducibility 的修复、文档更正、测试代码完善。这些都是真实有用的贡献，符合一个新贡献者“逐步进入项目”的正常模式。

任何成熟的开源项目都依赖这种渐进式信任建立。一个新贡献者通过一系列小贡献证明自己是可靠的、技术上能干的、对项目有兴趣的。维护者通过审核这些贡献逐步建立对此人的信任。这是开源协作模式的核心机制。

Jia Tan 完美地走了这个模式。在 2021 年底到 2022 年初的几个月里，他做的事都完全在正常贡献范围内。

但与此同时，邮件列表上开始出现一些奇怪的账号。

三

2022 年 4 月 22 日，一个叫 “Jigar Kumar” 的人在 xz-devel 邮件列表发了一封邮件。内容是抱怨：Jia Tan 之前提交的某个 patch 还没被合并6。

5 月 27 日，Jigar Kumar 又发了一封：“Over 1 month and no closer to being merged.”

6 月 7 日，Jigar Kumar 在另一个邮件主题下写道：

“Progress will not happen until there is new maintainer. XZ for C has sparse commit log too. Dennis you are better off waiting until new maintainer happens or fork yourself. Submitting patches here has no purpose these days. The current maintainer lost interest or doesn’t care to maintain anymore. It is sad to see for a repo like this.”7

6 月 14 日，Jigar Kumar 又一封：

“With your current rate, I very doubt to see 5.4.0 release this year. The only progress since april has been small changes to test code. You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo. Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?”

读这些邮件，注意几个细节：

  • 邮件直接 address 给 Lasse Collin（当前 maintainer）
  • 同时 Jigar Kumar 在 thread 里点名其他 mailing list 参与者（Dennis Ens），制造“多个独立用户都在抱怨”的氛围
  • 措辞接近羞辱（“lost interest”、“don’t care”、“choke your repo”）
  • 但都停在“我有合理批评”的边界以内，没有触及“这是骚扰”的程度

后续调查发现，Jigar Kumar、Dennis Ens、krygorin4545、misoeater91 都是 sock puppet 账号——使用一次性邮箱、2021 年后才创建、活动模式高度相似的虚假账号。Securelist、ReversingLabs 等独立的 threat intel 团队后续做的分析得出一致结论：这是一个有协调的 social engineering 行动，不是巧合8。

2022 年 6 月 29 日，在这些施压邮件下，Lasse Collin 回复了：

“my ability to care has been fairly limited mostly due to longterm mental health issues, but also due to some other things. Recently I’ve worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we’ll see.”9

这是一段值得停下来读的话。

Lasse Collin 是芬兰人，长年单人维护 xz Utils。他在公开邮件中承认两件事——他承认自己的 mental health 状态影响了维护精力；他承认 Jia Tan 已经在 off-list 帮助他，未来可能给 Jia Tan 更大角色。

后来的复盘里，安全研究者们看着这段话很沉重。Jia Tan 的 social engineering 选了一个完美的目标：一个公开承认了 mental health 困难的、单人维护关键基础设施的维护者。Jigar Kumar 等 sock puppet 的施压不是无差别的——它精准地利用了 Collin 已经在挣扎的状态10。

读 Collin 那封邮件，没办法把它解读成“他疏于职守”。他做的所有事都是合理回应：当多人施压时他承认压力；当一个志愿者愿意帮助时他接受帮助；当 mental health 影响精力时他诚实说出来。这件事最让人毛骨悚然的地方不是技术细节，是 social engineering 的精确度——它针对的是任何一个长期维护开源项目的人都可能有的情绪状态。

四

2022 年 10 月，Jia Tan 被加入 Tukaani 组织（xz Utils 在 GitHub 上的 organization）。 2022 年 11 月，Jia Tan 成为正式 co-maintainer。 2022 年 12 月，Jia Tan 第一次直接 commit 到 master 分支。 2023 年 1 月，Jia Tan 与 Collin 共同负责 v5.4.1 release。 2023 年 3 月，Jia Tan 独立发布 v5.4.2。同月，Google oss-fuzz（开源自动模糊测试服务）中 xz 项目的主要联系邮箱从 Collin 改为 Jia Tan11。

到这里 Jia Tan 已经在 xz Utils 项目里有完全的 trust 和 access。如果他从此停在这里——继续做正常 maintainer——没有人会怀疑他。但他还有下一步。

2023 年 6 月 22 日，一个叫 Hans Jansen 的账号出现，提交了一对 patch。内容是用 GNU ifunc（indirect function）特性优化 xz 的 CRC32 校验函数。这个优化看起来完全合理——ifunc 是 glibc 提供的运行时函数选择机制，允许程序在启动时根据 CPU 特性选最快的实现12。

Hans Jansen 不是 xz Utils 的常规贡献者——这是他对项目唯一的实质贡献。他在做完这个 patch 后就消失了。但他做的这个 ifunc 优化提供了攻击所需的关键基础设施：

ifunc 机制允许在程序启动时改变函数表指针。这正是后门后来用来劫持 OpenSSH 认证函数的机制。

但 2023 年 6 月那时候，没人知道这个 ifunc 优化的真正目的。它看起来是一个性能改进。Collin 审核了它，合并了它。Jia Tan 也参与了讨论。

回头看，Hans Jansen 这个账号被 ReversingLabs 等安全团队识别为第二个 sock puppet——跟 Jigar Kumar 那一组不同，他不参与施压，只贡献一段为后续 backdoor 服务的“合法看起来的”代码13。

整个 2023 年下半年到 2024 年初，Jia Tan 继续作为正式 co-maintainer 工作，正常处理 issue、合并 PR、发布更新。

五

2024 年 1 月，Jia Tan 把 xz Utils 项目的官方网站从 tukaani.org 迁到 GitHub Pages。这是一个看起来无害的运维改动——很多项目都用 GitHub Pages 托管文档。但效果是 Jia Tan 现在也控制了项目的“对外信息渠道”14。

2024 年 2 月 23 日，几个隐藏的二进制 blob 被合并到 xz Utils 的 test fixture 文件中。test fixture——测试用的输入数据——是一个不被严格 code review 关注的区域。维护者审核 commit 时主要看代码逻辑，不会逐字节查看测试数据文件。Jia Tan 把后门 payload 编码到了这些 fixture 中。

2024 年 2 月 24 日，xz Utils 5.6.0 发布。

关键点：后门不在 git 源代码 repository 里。

git repo 里只有看起来正常的代码 + 那些 test fixture 文件。后门的关键部分通过 build-to-host.m4 这个 autotools 配置脚本注入：在做 release tarball 时（也就是把 git repo 打包成 .tar.gz 给发行版用的步骤），m4 脚本会运行，把 test fixture 中的 payload 解码、组装、注入到 build 过程，最终编译进 liblzma 二进制15。

而且后门有非常精细的激活条件：

  • 只有当 build 在特定环境下（Debian/RPM 打包路径、特定 GCC 版本、特定 ld 链接器选项）才会激活
  • 在普通开发者 build（从 git clone 然后 ./configure && make）时不会激活
  • 只在 distribution 打包系统（用 release tarball 而不是 git source）build 时激活

这意味着如果你是个普通 xz 开发者，用 git 检出代码 build，你看不到后门。后门只在最终用户实际用的 Linux 发行版二进制里出现。这种“看 git repo 没问题但 release tarball 有问题”的攻击在历史上前所未有16。

后门的功能：劫持 OpenSSH 的认证函数。具体说，liblzma 的 ifunc resolver（Hans Jansen 2023 年加的那段代码）被改成在加载时改写 OpenSSH 的认证函数指针。当攻击者向 sshd 发送一个特定签名的认证请求时——签名用攻击者持有的 Ed448 私钥生成——sshd 会绕过常规认证流程，直接执行 payload。

这是一个完美的 backdoor：

  • 它需要私钥才能利用——所以即使后门暴露，只有持有私钥的人能用
  • 它通过 SSH 协议工作——攻击者从外部就能用，不需要先入侵
  • 它不留下日志——sshd 看起来正常处理了一次认证
  • 它针对的是 root 用户的 SSH 入口——一旦利用，攻击者获得 root 权限

如果未被发现，这会让攻击者在持有私钥的前提下，远程控制运行 xz 5.6.0/5.6.1 的任何 Linux 服务器。

六

但为什么 OpenSSH 会调用 liblzma？OpenSSH 自己不依赖 xz，它的源代码里没有 xz Utils。

答案是 systemd。

systemd 是 Linux 主流发行版的 init 系统（启动管理）。它管理着所有系统级守护进程——包括 sshd。systemd 自己依赖 liblzma（用于压缩 systemd journal 日志）。当 systemd 启动 sshd 时，sshd 进程会共享 systemd 的某些动态链接库——包括 liblzma。

这就是这次攻击的精确技术路径：

xz Utils 后门 → liblzma → systemd 加载 → sshd 进程间接得到 liblzma → 后门在 sshd 进程空间生效

这是一条间接但通用的路径。它不需要 sshd 自己知道 liblzma 存在。它依赖于 systemd 默认链接 liblzma 这个事实——而 systemd 是几乎所有主流 Linux 发行版的默认 init17。

更有意思的是：在 xz 后门嵌入的同一时段，systemd 项目正在评估一个 PR——移除 liblzma 依赖18。如果这个 PR 在 2024 年早些时候合并，xz 后门就会失去最关键的入口。Russ Cox 在他的复盘里推测，攻击者可能正是因为意识到这个 PR 而加快了行动——他们要赶在 systemd 改动之前完成后门部署。

七

回到 2024 年 3 月 9 日。

那天，Jia Tan 发布了 xz Utils 5.6.1——一个小的更新版本。commit message 里有一句话：

“constant seed was used to recreate these files.”

这看起来是个无关紧要的技术说明。但实际上是为了修复一些 Valgrind 已经能检测到的异常——5.6.0 中的后门有一些边缘情况会让 memory checker 报告 invalid read，攻击者要修复这些让发现更难。

2024 年 3 月底，开始有迹象表明攻击者在加快推进 xz 5.6.x 进入主流发行版。Hans Jansen 重新出现——3 月 27-28 日，他在 Debian 和 Ubuntu 的 bug tracker 上提交了 issue，催促这些发行版尽快采用 xz 5.6.1。这是 Hans Jansen 这个账号在 xz Utils 项目本身之外的唯一活动。它的目的明显：尽快把后门版本推进到稳定分支19。

如果 Hans Jansen 的催促成功，xz 5.6.x 会进入 Debian stable、Ubuntu LTS、Fedora 的下一个稳定 release。等到那时——预计 2024 年 4-6 月——后门会扩散到全球数千万到数亿台生产 Linux 服务器。

但 2024 年 3 月 28 日，Andres Freund 在 PostgreSQL 性能测试里注意到了 SSH 的 500ms 异常。

八

把这个故事的所有关键节点放在一起，会看到一个让人不安的对称。

Phase 1：建立信任（2021 年 10 月 - 2022 年初）

  • Jia Tan 提交几个无害的小贡献
  • 通过正常 OSS 渐进信任机制进入项目

Phase 2：制造维护压力（2022 年 4-6 月）

  • Jigar Kumar、Dennis Ens 等 sock puppet 在邮件列表施压
  • 措辞精准地利用 Collin 已知的 mental health 困境
  • 形式上完全在“合理批评”的边界以内

Phase 3：权限升级（2022 年 10 月 - 2023 年 3 月）

  • 加入 Tukaani 组织
  • 成为 co-maintainer
  • 独立发布版本
  • 接管 oss-fuzz 联系邮箱

Phase 4：技术准备（2023 年 6 月）

  • Hans Jansen 这个新 sock puppet 提交 ifunc 优化
  • 这是后门后来利用的技术机制
  • Hans Jansen 完成任务后消失

Phase 5：嵌入后门（2024 年 2 月）

  • 把 payload 编码到 test fixture
  • 通过 m4 配置脚本在 build 时注入
  • 后门只在发行版打包时激活，开发者 build 看不到

Phase 6：推进部署（2024 年 3 月）

  • Hans Jansen 重新出现，催促 Debian、Ubuntu 采用 5.6.x
  • 目标是在 systemd 改动之前进入稳定分支

整个攻击从开始到几乎成功，约 2.5 年。期间动用了至少 5 个不同身份（Jia Tan、Jigar Kumar、Dennis Ens、Hans Jansen、krygorin4545 / misoeater91 等）。每个身份都精心设计：写作风格、邮件时区、活动模式都尽量分散。技术上极其精巧：通过 m4 hook + test fixture + ifunc + systemd 的复合机制，最终劫持 OpenSSH 认证20。

只有国家级行为者能负担这种行动的成本。一个或几个研究员需要全职投入近 3 年时间，做出能逃过开源社区代码审查的复杂技术，同时演出合理的 social engineering 戏码。算下来人力成本至少几百万美元，更不用说技术研发成本。

九

归因这件事必须谨慎。

到 2026 年 5 月为止，没有任何政府机构正式归因这次攻击给具体国家或组织。

公开材料中可分析的线索：

  • Jia Tan 的 commit 时区始终在 UTC+02 到 UTC+09 之间——覆盖东欧到东亚的极宽范围，无法精确定位
  • 部分 commit 时间窗口与中国春节、东欧节假日并不冲突
  • 写作风格、错误模式、commit message 习惯都经过精心校准，难以从语言学证据指向特定母语区

美国 CISA、Mandiant、Kaspersky、ReversingLabs、Elastic Security 等独立 threat intel 团队在公开报告里一致使用了类似措辞：“This attack pattern is highly consistent with known nation-state actor TTPs, but attribution cannot be definitively established.”21

这种判断是诚实的。从技术能力、时间投入、心理操纵的精度看，xz 攻击只可能来自国家级行为者或同等规模的资源。但具体是哪一个国家，公开材料不允许定论。Russ Cox 在他的 timeline 复盘里也明确：归因不能成立22。

媒体和社交网络上有大量推测——指向俄罗斯 SVR、朝鲜 Lazarus、中国 MSS、以色列 Unit 8200、甚至美国 NSA 内部“红队”。所有这些推测都没有可证据基础。这本书的立场跟 Russ Cox 一致：嫌疑指向国家级行为者，但具体归因不能成立。

十

不能归因不意味着我们不能学到什么。

xz 攻击让安全研究界第一次直接看清了一种攻击模式的完整面貌：

1. Target selection（目标选择）

  • 关键基础设施（被全球数亿台机器使用）
  • 单人或极小团队维护（更容易渗透）
  • 维护者有公开可见的脆弱点（mental health 自述、burnout 抱怨等）

按这个标准，全球开源生态里还有几百个类似项目。xkcd 2347 的“内布拉斯加的某个人”——他们每一个都是潜在 target。

2. Long-term investment（长期投入）

  • 2-3 年的时间尺度
  • 多个虚假身份的协同
  • 真实的技术贡献（不只是骗信任，要做出对项目有用的工作）

这种规模的投入只有国家或国家支持的行为者能负担。普通网络犯罪不会等 3 年看回报。

3. Multi-layer technical complexity（多层技术复杂度）

  • 后门不在 source repo 而在 release tarball
  • 通过 build-time hook 注入（autotools m4）
  • 利用 ifunc 改写函数指针
  • 通过 systemd 间接到 OpenSSH
  • 加密的激活条件（持有 Ed448 私钥）

每一层都需要专门知识。整体设计需要对 Linux build system、动态链接器、systemd 架构、OpenSSH 内部、密码学的深入理解。

4. Operational security（行动安全）

  • 多个 sock puppet 账号的协同使用
  • 跨多个时区的 commit 分布
  • 不同身份分担不同角色（建立信任 / 施压 / 提供技术基础 / 推进部署）
  • 完成任务的账号会消失

整个行动几乎没有可被识别的“个人特征”。即使在事后复盘，研究者也只能描述行动模式，不能识别个人。

十一

xz 后门跟历史上的两次“国家级供应链攻击”做对比：

SolarWinds（2020）：俄罗斯 SVR 在 SolarWinds Orion（一个商业网管软件）的 build 过程中注入了 SUNBURST 后门。攻击影响约 18,000 个 SolarWinds 客户，包括美国国务院、财政部、Microsoft、Intel 等。这是 闭源 供应链攻击：攻击者通过侵入 SolarWinds 公司内部，在私有 build 系统里注入代码23。

3CX（2023）：朝鲜 Lazarus Group 通过攻击 Trading Technologies 公司的软件，然后通过这个软件感染 3CX（一个 VoIP 软件），最终影响 3CX 的 60 万企业客户。这是 双层闭源 供应链攻击24。

xz Utils（2024）：来源未归因的国家级行为者，通过 social engineering 接管一个开源项目的 maintainer 权限，然后注入后门。

三个事件的关键不同：

维度SolarWinds3CXxz Utils
目标软件类型闭源商业闭源商业开源
入侵方式入侵公司内网双层供应链入侵Social engineering 维护者权限
攻击预备时间数月数月2-3 年
被发现方式FireEye 内部红队用户报告异常个人工程师偶然
修复方式SolarWinds 紧急 patch3CX 紧急 patch回退 xz 版本
归因美国正式归因俄罗斯 SVR美国正式归因朝鲜 Lazarus未归因

闭源供应链攻击让人警惕——它证明了“专有软件 + 公司内部 build 系统”不是安全保证。但开源供应链攻击让人更不安——它证明了“公开代码 + 社区审查”也不是安全保证。

xz 唯一被发现是因为运气。在那 2.5 年里，没有任何安全审计、自动化扫描、社区代码审查发现了 Jia Tan 的真正身份或意图。即使 ifunc 优化、test fixture、m4 hook 都在公开 git history 里，没有人在嵌入时识别出它们的真正含义。

只有 Andres Freund 在 2024 年 3 月做 PostgreSQL benchmark 时——一个跟 xz Utils 完全无关的工作场景——偶然发现 SSH 慢了 400ms。如果他那天没注意到，或者他像 99% 的工程师那样忽略了，xz 后门会进入下一个月的 Debian stable。然后 6 个月内进入全球大部分 Linux 服务器。

十二

xz 暴露的最深的问题不是 OpenSSL 的“单人维护”，是社区审查在国家级行为者面前的失效。

回到 Eric Raymond 1997 年 Cathedral 和 Bazaar 那篇文章里的著名命题——“Given enough eyeballs, all bugs are shallow”25。这个命题假设：开源代码的公开性让足够多的眼睛看到代码，所以 bug 都会浅显。

Heartbleed 在 2014 年第一次质疑了这个命题——一个 bug 在公开代码里活了 17 个月，最后被两个独立团队几乎同时发现。Log4Shell 在 2021 年继续质疑——一个 bug 在公开代码里活了 8 年。

但 Heartbleed 和 Log4Shell 都是无意 bug。它们没主动隐藏自己。“足够多的眼睛”的失败是因为代码太复杂、审查者太少、激励不对齐——但理论上眼睛足够多就能发现。

xz Utils 是主动隐藏的后门。Jia Tan 不只是没主动暴露自己的真意——他在整个 2.5 年里精心避免任何能让审查者发现真意的痕迹。他做的所有真实贡献都对项目有益。他的所有施压邮件都通过 sock puppet 发出，他自己的 commit 全部技术中性。他的 commit message 都写得完美。

在这种“对手主动隐藏”的情境下，“足够多的眼睛”不再有用——因为眼睛看到的是被精心设计的合理表象。要发现 xz 后门，需要的不只是审查眼睛，是对维护者身份的可验证性、对 build 过程的可验证性、对供应链 provenance 的可验证性。

这正是 SLSA、Sigstore、Reproducible Builds 这些新一代供应链安全工具要解决的问题。但它们也有限度——下一章我们会讲这些工具的设计和它们没解决的部分。

十三

最后回到那个 500ms 异常。

Andres Freund 在 Mastodon 上写过一段复盘：他强调自己不是安全研究员，他是一个性能工程师。他注意到 SSH 慢了不是因为他特别警觉——是因为他每天都在看 PostgreSQL 的性能曲线，对“什么东西比预期慢”有职业习惯26。

如果换一个非性能背景的工程师在那台 Debian Sid 上——比如一个 web 开发者，一个机器学习研究员——他们大概率不会注意到 SSH 慢了 400ms。SSH 100ms vs 500ms 在日常使用中几乎感受不到差别。是 Freund 的具体职业偏见（“为什么这个比预期慢”）救了所有人。

这件事在 OSS 安全圈引起了一种特殊情绪。一方面是庆幸——后门被发现了，损失被避免了。另一方面是恐惧——这不是制度的胜利，是偶然的胜利。如果换一个人，结果就是另一个故事。

xz 之后两年——从 2024 年 4 月到 2026 年 5 月——没有发生第二次类似的、被识别的国家级 OSS 后门事件。但几乎所有公开发言的安全研究者都指出同一件事：这不是因为没有第二次，是因为还没被发现。

如果一次行动需要 2.5 年才能成熟，那么 2024 年 3 月之后开始的下一次行动，可能要 2026 年下半年或 2027 年才会被尝试。当我们在 2026 年 5 月写这本书时，第二次可能正在 mid-flight——正在某个我们不知道的 xkcd 2347 项目里，某个被 social engineering 的维护者旁边，某个新的 Jia Tan 正在合并某个看起来无害的 patch。

下一章我们要看的是这个故事的另一面——维护者本人的处境。Lasse Collin、Daniel Stenberg、Ralph Goers、Andres Freund，他们不是案例，是有血有肉的人。他们的具体处境决定了 xz 这种攻击为什么是可能的——以及为什么不可能简单消除。

References

  1. Wikipedia: XZ Utils backdoor. 包括 Andres Freund 的发现过程基础描述。Link →

  2. Andres Freund 在 Mastodon 与 oss-security 邮件列表的 2024-03-29 复盘。Elastic Security Labs 的 “500ms to midnight” 提供详细记录。Link →

  3. Akamai: “XZ Utils Backdoor — Everything You Need to Know”. 关于 build-to-host.m4 注入机制的技术描述。Link →

  4. Red Hat: “Understanding Red Hat’s response to the XZ security incident”. 2024-03-29 紧急响应记录。Link →

  5. research!rsc: “Timeline of the xz open source attack” by Russ Cox. 包括 2021-10-29 第一次 Jia Tan commit 的详细记录。Link →

  6. Russ Cox, ibid. Jigar Kumar 邮件时间线。

  7. Jigar Kumar 2022-06-07 邮件原文，从 xz-devel mailing list 归档。Russ Cox 与 Securelist 都引述了这段。

  8. Securelist: “Social engineering aspect of the XZ incident”. 包括 sock puppet 协调分析。Link →

  9. Lasse Collin 2022-06-29 邮件回复原文。从 xz-devel mailing list 归档；Russ Cox 完整引述。

  10. ReversingLabs: “XZ Trojan highlights software supply chain risk posed by ‘sock puppets’”. 关于 social engineering 精确度的分析。Link →

  11. Russ Cox, ibid. 关于 Jia Tan 权限升级时间线 + oss-fuzz 联系邮箱变更。

  12. Russ Cox, ibid. Hans Jansen 2023-06-22 ifunc patch 描述。

  13. ReversingLabs, ibid. 关于 Hans Jansen 作为第二组 sock puppet 的分析。

  14. Russ Cox, ibid. 2024-01 网站迁移到 GitHub Pages。

  15. Checkmarx: “Backdoor Discovered in xz”. build-to-host.m4 与 release tarball vs git repo 的关键区分。Link →

  16. arxiv: “On the critical path to implant backdoors and the effectiveness of potential mitigation techniques: Early learnings from XZ”. 技术深度分析。Link →

  17. Akamai, ibid. 关于 liblzma → systemd → sshd 链条的技术细节。

  18. Russ Cox, ibid. 关于 systemd PR 移除 liblzma 的推测。

  19. Evan Boehs: “Everything I Know About the XZ Backdoor”. 关于 Hans Jansen 2024-03 重新出现催促 Debian / Ubuntu 的细节。Link →

  20. daily.dev: “XZ Backdoor: The full story in one place”. 综合时间线。Link →

  21. CISA、Mandiant、Kaspersky、ReversingLabs、Elastic Security 等团队 2024-04 至 2024-12 的 xz 系列分析报告。全部使用“高度匹配国家行为者 TTP 但归因不能成立”的措辞。

  22. Russ Cox, ibid. 关于归因开放性的明确表态。

  23. Wikipedia: 2020 United States federal government data breach (SolarWinds). Link →

  24. Krebs on Security: “3CX Breach Was a Double Supply Chain Compromise”. Link →

  25. Eric S. Raymond, “The Cathedral and the Bazaar” (1997). “Linus’s Law” 的来源。Link →

  26. Andres Freund 2024-04 Mastodon 复盘。“I am not a security researcher”——强调发现 is luck。Elastic Security Labs 全文引述。

  27. SoftwareSeni: “The XZ Utils Backdoor CVE-2024-3094 and the Multi-Year Social Engineering Campaign Behind It”. 综合性中文向分析。Link →

  28. Rapid7: “Backdoored XZ Utils (CVE-2024-3094)”. Link →

  29. JFrog: “XZ Backdoor Attack CVE-2024-3094: All You Need To Know”. 包括技术深度分析。

  30. Snyk: “The XZ backdoor CVE-2024-3094”. 包括对供应链长期含义的分析。