【安全观察】xz 后门启示录

“

本文不揣测 xz 后门背后的团伙与动机，只为学习目的，以便吸取教训。

xz 后门事件的完整时间线

2024 年 3 月 29 日，Openwall OSS-security 邮件列表上的一条信息对于信息安全、开源和Linux社区来说标志着一个重要的发现：在 XZ 中发现了一个恶意后门。XZ 是集成在许多流行的 Linux 发行版中的压缩实用工具。

“

XZ Utils 几乎在 Linux 上无处不在。它在几乎所有类 Unix 操作系统上提供无损数据压缩，包括 Linux。XZ Utils 在各种操作中提供了压缩和解压数据的关键功能。XZ Utils 还支持传统的 .lzma 格式。.lzma 格式因其高压缩率和可选的高压缩设置而受到青睐，尤其适用于大文件的压缩。.lzma 常用于操作系统镜像、大型游戏或应用程序的安装包、数据备份等场景。

下面是来自卡巴斯基[1]关于 xz 后门事件的时间线。

2024.01.19 XZ 网站由新的维护者（ jiaT75[2]）迁移到 GitHub 页面
2024.02.15 添加[3]“build-to-host.m4” 到.gitignore
2024.02.23 引入[4]了两个包含恶意脚本阶段的“测试文件”
2024.02.24 发布了 XZ 5.6.0
2024.02.26 在 CMakeLists.txt 中 commit[5] 破坏 Landlock[6] 安全功能的代码
2024.03.04 后门导致 Valgrind 出现问题[7]
2024.03.09 更新了两个“测试文件”，修改了 CRC 函数，修复了 Valgrind 问题
2024.03.09 XZ 5.6.1 发布
2024.03.28 发现 bug，已通知 Debian 和 RedHat
2024.03.28 Debian 将 XZ 5.6.1 rolls back[8] 到 5.4.5-0.2 版本
2024 年 03 月 29 日，在 OSS-security 邮件列表上发布[9] 了一封电子邮件
2024 年 03 月 29 日，RedHat 确认在 Fedora Rawhide 和 Fedora Linux 40 beta 中发布[10] 了带后门的 XZ
2024 年 03 月 30 日，Debian 关闭[11]构建并开始重新构建的过程
2024.04.02 XZ 主要开发人员承认[12] 后门事件

正所谓：

黑客潜藏计中计，暗渡陈仓码未宁。

人算终难如天算，竹篮打水空归行。

技艺虽能迷目眼，漏洞反被 Bug 误。

尘世安有尽全策，百密一疏漏自明。

为什么说 xz 后门是「核弹级」后门

这个后门与常规的供应链投毒完全不同，如果它成功实施攻击，那么全球范围内的 SSH 服务器都将遭到控制。攻击者可以通过该后门将任意代码注入到最终进入敏感进程地址空间的库中。

但，

“

“攻击非常隐秘，只有在使用amd64（英特尔x86 64位）构建库并构建Debian或RPM软件包（而不是用于本地安装）时，才会执行后门的最后步骤。”

为什么 xz 后门如此有针对性？ （此处为 ChatGPT 的分析）

xz 后门展现出如此高度的针对性，主要是为了确保其行动的隐蔽性和效率。这种针对特定平台和构建环境的设计允许攻击者更精确地控制后门的激活，减少被发现的可能性，并提高攻击的成功率。以下是一些可能的原因和目的分析：

减少被发现的风险：针对特定的系统和构建环境（如 amd64 架构的 Debian 或 RPM 系统），可以帮助确保恶意行为在大多数测试和开发环境中不会被触发，从而减少在开发和预发布测试阶段被发现的几率。
提高攻击效率：针对最广泛使用的发行版和架构（如基于 amd64 的 Debian 和 RPM 发行版），可以增加攻击覆盖的广度和深度，因为这些系统在服务器和桌面环境中极为常见，是高价值的目标。
利用特定环境特性：特定构建环境可能具有独特的安全配置或漏洞，攻击者可能已经详细分析了这些环境，发现了可以利用的特定弱点。

这样做的危害如下：

窃取敏感信息：如果后门主要针对服务器和常见的桌面环境，那么其目的可能是窃取商业机密、用户数据或其他敏感信息。服务器环境通常存储了大量的敏感数据，对攻击者具有很高的吸引力。
建立持久的访问：后门可能用于在受影响的系统上建立持久的访问，为未来的攻击活动铺路。这可以包括部署额外的恶意软件、创建隐秘的后门账户等。
为大规模网络攻击做准备：攻击者可能在准备进行更大规模的网络攻击，例如分布式拒绝服务攻击（DDoS）、勒索软件攻击或广泛的网络间谍活动。
破坏关键基础设施：在针对特定架构和发行版的情况下，后门的部署可能旨在破坏或干扰关键的基础设施和服务。

看得出来，xz 后门如果成功以后，绝对算得上是「核弹级」后门了。XZ Utils 的后门被分配漏洞编号是 CVE-2024-3094[13]，并具有CVSS最高的严重性评分 10 分。

xz 后门实施的关键阶段分析

从互联网上披露的各种关于 xz 后门的资料总结，xz 后门的实施包含四个关键阶段：

取得维护者信任：攻击者通过长期参与项目，逐步建立信任，最终获得项目维护者的地位。这一过程中，攻击者可能通过提交看似正常的代码改动或修复，慢慢渗透到项目核心团队中。
源码修改：攻击者在取得足够权限后，开始在项目源代码中引入恶意代码。这些代码可能是直接的恶意功能，也可能是为后续更深入攻击准备的钩子或后门。
编译阶段的链接与混淆：在项目的编译阶段，攻击者利用复杂的 Bash 脚本和 m4 宏来进一步隐藏恶意代码的存在。这些脚本在构建过程中被执行，它们可能修改构建配置，植入更多的恶意代码，或者对生成的二进制文件进行后处理。
修改 .so共享文件：攻击者通过修改动态链接库（如 liblzma.so），在这些广泛使用的库中植入后门。这使得所有依赖这些库的应用程序都可能在运行时无意中执行恶意代码。
后门触发与利用：一旦后门被植入并部署到目标系统中，它可以通过特定的触发条件被激活。例如，某些特定的网络请求或用户操作可能触发后门，允许远程攻击者执行代码、窃取数据或控制受影响的系统。

看得出来，这是一次经过精心策划的供应链攻击。涉及从项目参与、代码修改、编译过程控制到最终的后门植入与利用。这种攻击不仅要求攻击者具备深厚的技术知识和对目标项目的深入理解，还涉及社会工程学，使其能在不被发现的情况下持续操作较长时间。

社会工程学：取得维护者信任

这是攻击的第一步，也是最重要的一步。

一句话总结信任建立的基础：原维护者疲惫不堪，只有攻击者提供帮助。

网上有人找到了一个包含攻击者 Jia Tan 和 xz 作者，以及一些用户交流的电子邮件线程的存档[14] ，记录了这一切的开始。

“

某用户："XZ for Java 仍然维护吗？我在这里一个星期前提出了一个问题，但没有得到回复。"

xz 作者："是的，至少按某种定义，比如如果有人报告错误，它会被修复。开发新功能肯定不是很活跃。“

xz 作者：" Jia Tan 帮助了我...他可能在未来扮演更重要的角色...很明显，我的资源太有限了...所以从长远来看必须做出一些改变。"

某用户：“只有有新的维护者，才会有进展……现任维护者失去了兴趣或不再关心维护。对于这样的仓库来说，这真是令人伤心。”

xz 作者：“我对此并没有失去兴趣，但由于长期的心理健康问题以及其他一些原因，我关心的能力相当有限。请记住，这是一个无偿的业余项目。”

某用户：“你忽视了这个邮件列表上许多正在腐烂的补丁。现在你的仓库被堵塞了。为什么要等到 5.4.0 才更换维护者？为什么要延迟你的仓库所需的改变？”

某用户："对于你的心理健康问题我感到抱歉，但是重要的是要意识到自己的限制。我知道这是所有贡献者的爱好项目，但是社区需要更多"

某用户：“为什么不将XZ for C的维护工作交给其他人，这样你就可以更专注于XZ for Java了？或者将XZ for Java交给其他人，让他们专注于XZ for C？试图同时维护两者意味着两者都无法得到很好的维护。”

xz 作者：“寻找一个共同维护者或完全将项目移交给其他人一直在我的脑海中，但这并不是一件简单的事情。例如，某人需要具备技能、时间和足够长期的特定兴趣来做这件事。”

xz 作者：" Jia Tan 可能在未来的项目中扮演更重要的角色。他在列表之外提供了很多帮助，实际上已经是一个共同维护者了。:-)"

看完这份摘要，我感觉这像是一场隐藏在 xz 邮件列表中对作者的一场"网暴"。

我有理由怀疑，JiaTan 不是一个人在战斗。要实施这场攻击，并想提升 xz 作者对他的信任的概率，那应该有一些“团伙”。JiaTan 唱红脸，团伙唱白脸，这种左右夹攻下让 xz 作者交出了项目的维护权。

就这样 JiaTan 的第一步攻击完成，开始了他长达一年的潜伏。

“

2023 年 1 月， JiaTan 首次向 XZ Utils 提交了代码。在接下来的几个月里，使用 Jia Tan 这个名字越来越多地参与了 XZ Utils 的事务。例如，Tan 在 oss-fuzz 上用自己的联系信息替换了 Collins （xz 作者）的信息，oss-fuzz 是一个扫描开源软件漏洞的项目。Tan 还要求 oss-fuzz 在测试期间禁用 ifunc 函数，这个改变阻止了它检测到 Tan 不久后对 XZ Utils 进行的恶意修改。

源码修改，构造后门

今年 2 月，Tan 发布了 XZ Utils 5.6.0 和 5.6.1 版本的提交。这些更新中实施了后门。

这个后门分为下面几个组件：

上游发布的发行版 tarballs 与 GitHub 上的代码不同。这在 C 项目中很常见，这样下游消费者就不需要记住如何运行 autotools 和 autoconf。发行版 tarballs 中的 build-to-host.m4 版本与 GitHub 上游的版本差异很大。
在 git 仓库的 tests/ 文件夹中有一些精心制作的测试文件（tests/files/bad-3-corrupt_lzma2.xz 和 tests/files/good-large_compressed.lzma）。(这些文件包含 shell 脚本和后门二进制对象自身)。
一个由 build-to-host.m4 调用的脚本，解压这个恶意测试数据并使用它来修改构建过程。
IFUNC，glibc 中的一种机制，允许进行间接函数调用，用于执行 OpenSSH 的身份验证例程的运行时 hooking 或重定向。IFUNC 是一种正常调用机制，但是被 xz 后门用于攻击。

只要满足了特定的条件，比如 amd64/x86_64 架构上构建 Debian 或 Red Hat 软件包时，就能激活攻击 Payload 。目前安全研究人员并不确定这个 payload 的目的是什么，还在调查中。

“

xz 的作者 Lasse Collin 正在对 xz.git 进行审计[15]。（Collin 有定期的「离线隐居」的习惯，在 xz 后门被发现那几天，他正在隐居）

payload 被间接加载到 sshd 中。

任何库都可以篡改与其链接的任何可执行文件的内部工作方式。OpenSSH 是最流行的 sshd 实现，它不链接 liblzma 库，但 Debian 和许多其他 Linux 发行版会添加一个补丁，将 sshd 链接到 systemd ，这是一个在系统启动期间加载各种服务的程序。而 systemd 又链接到 liblzma，这使得 XZ Utils 可以对 sshd 施加控制。

“

最新：OpenSSH 开发人员已经添加了systemd-notify 协议的非库集成[16]，因此发行版将不再通过 libsystemd 支持进行修补。这个改变已经提交，并将在OpenSSH-9.8中实现，预计在2024年6月/7月发布。

如果此 payload 被成功加载到 openssh sshd 中， RSA_public_decrypt 函数将被重定向到恶意实现。攻击者必须提供一个由 pyaload 验证的密钥，然后将攻击者的输入传递给 system() ，从而实现远程代码执行（RCE）。

编译阶段的链接与混淆

在现代软件开发中，尤其是在 Unix-like 系统中，构建和编译过程通常涉及多种工具和脚本，以实现软件的自动化构建和配置。xz作为一个流行的压缩工具，其编译过程也使用了这些常见的工具，包括 Bash 脚本和 m4 宏。

Bash脚本：

自动化构建和配置任务：Bash脚本通常用于自动化日常的构建和配置任务，例如检查系统环境（如操作系统类型、安装的库和工具等），执行配置前的准备工作，以及调用其他构建工具（如make）。
灵活性和可移植性：Bash脚本提供了高度的灵活性，可以在几乎所有Unix-like系统上运行，这对于跨平台软件的构建尤其重要。

m4宏：

生成可移植的shell脚本：m4 宏是一种宏处理器，它可以扩展文本和生成重复的代码段。在软件构建过程中，m4 宏常与autoconf工具一起使用，来生成可移植的shell脚本（configure脚本），这些脚本随后用于生成适合特定系统的Makefile。
简化复杂的配置：m4 宏处理器可以处理复杂的文本替换和条件检查，这在处理各种不同系统和环境配置时极为有用。它允许开发者编写一套配置文件，自动适应多种编译环境。

m4 宏是一种广泛使用的宏处理语言，其功能包括定义宏、展开宏、条件测试、包含文件等。m4 特别适用于生成文本文件和自动化脚本，因此它被广泛用于软件开发中，尤其是与autoconf一起用于生成配置脚本。这些配置脚本可以检测主机环境的各种特性，如操作系统类型、编译器选项、外部库等，以确保软件能在特定环境下正确编译和运行。

在xz的编译过程中，autoconf和 m4 宏用于生成configure脚本。这个脚本是一个 shell 脚本，它在编译前运行，用于检查系统特性和配置参数。一旦configure脚本运行完毕，它会生成适合当前系统的 Makefile，然后开发者可以运行make命令来编译和链接最终的程序。整个过程中，Bash 脚本可能用于自动化执行这些命令，处理编译后的任务，或进行清理工作。

xz 后门通过在 Bash 脚本中使用多阶段的混淆和加密技术来隐藏其行为。在安全工程师 Gynvael Coldwind [17] 的文章中对这几个阶段进行了分析（细节可以查看原文）。

阶段 0 : 修改脚本

起始点：一段在m4/build-to-host.m4文件中的代码。这段代码在构建过程中被执行。
关键命令：
sed和tr：这两个命令被用来处理和修改从测试文件中读取的数据。sed用于流编辑，而tr用于字符转换。
示例：tr "A-Z" "N-ZA-M" 这是一个简单的字符替换例子，其中将所有英文字母替换为其对应的字母（ROT13加密）。

在这个阶段，混淆主要通过字符映射（使用tr命令）来实现，目的是将损坏的数据“修复”为可执行的代码。即，这实际上“修复”了测试数据 bad-3-corrupt_lzma2.xz，并将输出导入到 xz -d 命令中，该命令用于解压数据。解压后的数据包含一个 shell 脚本，之后将使用 /bin/bash 执行，由该 .m4 文件触发。

阶段 1 ：注入 shell

执行环境检查：脚本首先检查是否在Linux系统上运行。
数据流操作：该阶段使用多个head命令来选择性地读取或忽略数据流中的特定部分。这些命令提取了 33,492 字节（2048 * 16 + 724 字节）。然后，tail 命令保留文件的最后 31,265 字节，并忽略其余部分。

这一阶段的关键在于对数据进行精确的处理，以提取隐藏在数据中的第二阶段脚本。之后，tr 命令对输出进行基本替换以解密。第二个 XZ 命令将转换后的字节作为原始 lzma 流进行解压缩，然后将结果传送到 shell。

阶段 2 ：提取后门

最后一个阶段的 shell 脚本执行许多检查，以确保它在预期的环境中运行，例如项目是否配置为使用 IFUNC（将在下一节中讨论）。

功能拓展机制：引入了一种机制，可以在不更改原始测试文件的情况下，通过添加新的测试文件来注入新的脚本。
脚本执行：提取并执行隐藏在数据中的脚本，这些脚本可以进一步修改软件的构建过程。在某个时候，后门.o文件（隐藏于 good-large_compressed.lzma 中）被提取出来并将其编织到后续的编译/链接过程中。

第二阶段整个过程基本上看起来像是一个“扩展/修补”系统，允许添加将在第二阶段上下文中运行的未来脚本，而无需修改原始的携带测试文件的有效负载。这应该是精心设计的，因为一遍又一遍地修改“坏”和“好”的测试文件非常可疑。因此，计划似乎是只添加新的测试文件，这些文件将被捕获、解密和执行。

“

还可能有后面的阶段，但是 Gynvael 认为后面的阶段并没有实施完成。

总的来说，攻击者为了使其看起来相当无害和相当隐蔽而付出了很多努力。从用于存储 payload 的二进制测试文件，到文件切割、替代密码和在 AWK 中实现的 RC4 变体，所有这些都只使用了标准命令行工具。而且所有这些都在三个执行阶段完成，并且还有一个“扩展”系统，以免再次更改二进制测试文件。

如果这个后门是被偶然发现的，还有多少事情仍然未被发现？

修改 `.so`共享文件

“

卡巴斯基[18]对此有详细的总结，另外 binarly-io/binary-risk-intelligence[19] 对 liblzma.so 也有更详细的分析。

在原始的 XZ 代码中，有两个特殊的函数用于计算给定数据的 CRC：lzma_crc32 和 lzma_crc64。这两个函数都以 IFUNC 类型存储在 ELF 符号表中，这是 GNU C 库（GLIBC）提供的一个特性。IFUNC 允许开发人员在动态链接器加载共享库时动态选择正确的函数使用。

XZ 使用这个的原因是它允许确定是否应该使用lzma_crcX函数的优化版本。优化版本需要现代处理器的特殊功能（CLMUL、SSSE3、SSE4.1）。这些特殊功能需要通过发出 cpuid 指令来验证，该指令使用 GLIBC 提供的 __get_cpuid 包装器/内嵌函数调用，而后门利用这一点来加载自身。

后门被存储为一个目标文件，其主要目标是在编译过程中与主可执行文件链接。目标文件包含 _get_cpuid 符号，因为注入的 shell 脚本从原始源代码中删除了一个下划线符号，这意味着当代码调用 _get_cpuid 时，实际上调用的是后门的版本。

初始后门代码被调用两次，因为 lzma_crc32 和 lzma_crc64 都使用了相同的修改函数(_get_cpuid)。为了确保对此的控制，创建了一个简单的计数器来验证代码是否已经执行过。当 lzma_crc64 IFUNC 调用_get_cpuid 时，看到计数器值为 1，表示该函数已经被访问过，并启动最后一步将重定向到此恶意软件的真正入口点。

为了初始化恶意代码，后门首先初始化了一些保存当前运行进程核心信息的结构。主要是使用硬编码的偏移量定位全局偏移表（GOT）地址，并利用这些信息在其中找到 cpuid 指针。

GOT 包含符号的偏移量，包括 cpuid 包装器。然后，后门交换指向主要恶意软件函数的指针，并将其调用，就像调用 cpuid 一样。

后门的主要目标是成功挂钩特定函数，以允许其监视对受感染机器的每个连接。目标函数包括：

目标函数

描述

RSA_public_decrypt

由 libcrypto 使用，用于解密由私钥签名的密文

EVP_PKEY_set1_RSA

由libcrypto用于设置给定上下文的RSA密钥

RSA_get0_key

由 libcrypto 用于检索 RSA 密钥

然而，对于后门来说，挂钩所有这些函数并不是一项简单直接的任务。它涉及访问许多内部结构并操纵进程特定的结构，直到达到其目标，并且还需要尽可能地隐蔽，这意味着恶意代码包含多个检查以避免被分析，比如检查是不是 sshd 进程，否则就停止执行等。

另外还使用了特别的字典树来进行字符串操作等技巧来让后门分析变得更加复杂，有利于隐藏自身。xz 后门还包含一个内部的简化反汇编器，用于指令解码。它在寻找特定值（如 *audit 地址）时广泛使用。

看得出来，构建和感染该后门的手段设计的非常复杂。

后门是如何被发现的

那如此精心设计的 xz 后门是如何被发现的呢？完全始于一次偶然。

一位名为 Andres Freund[20] 的 Linux 数据库 PostgreSQL 的“维护者”在 Openwall 的邮件中首次披露：xz/liblzma 中的后门导致 ssh 服务器受损。

Andres 在 Debian sid 安装中观察到 liblzma（xz 包的一部分）出现了一些奇怪的症状，比如使用 ssh 登录会占用大量 CPU，以及 PostgreSQL 用户发现一个Valgrind 错误。经过一番调查，他发现了 xz 的后门。

这个后门占用 CPU 的原因可能如下：

它在每个连接上执行了额外的 ECC 操作，但在现代 CPU 上不应该需要 500 毫秒。（关于 ECC 的另一个有趣的事情是，它们使用的是 Ed448，与传统的 P-256 或 Ed25519 相比，速度要慢得多，大约慢 30 倍的验证速度）
对后门做逆向工程的研究人员说，它还要求将命令消息绑定到 ssh 主机密钥，所以如果主机密钥是 RSA 密钥，那么它可能在每次连接时执行额外的 RSA 解密操作。
启动时的 ELF 解析和内存中的反汇编导致延时（自定义的 ELF 解析器和反汇编器非常复杂）。
隐藏行迹所用的字符串混淆的查找都需要额外的计算周期。
进行了大量的符号和指令查找。

Valgrind 错误可能的原因：无效的内存写入。valgrind 错误通过禁用 ifunc 被修复了，因此也禁用了后门，因此错误消失了。

Rust 语言能阻止 xz 后门级别的攻击吗？

“我对 C 的质量非常满意，但对 M4 不太满意。在供应链攻击方面，Cargo 是我见过的最糟糕的” —— 某位 hackernews 用户。

他是在说反话吗？ 我认为是的，和 C 比应该不是最糟糕的。

这次 xz 后门攻击的主要技术手段是在于构建系统。Cargo 是否能够防止这种攻击？不一定，因为 Cargo 支持 build.rs 构建脚本，可以干任何事情。所以像在 Google Android / 华为鸿蒙等操作系统里引入 Rust 都已禁用了 build.rs 来保障安全。 Rust 的过程宏也是帮助构建后门的一种手段，同样可以做任意事情。

然而，Rust 官方在供应链安全上也在发力，进一步增强 Security 安全保障。关于 Rust 供应链安全机制我在之前的公众号文章《一篇文章带你全面了解 Rust 与安全》里有介绍。

但是对于 xz 后门这种综合了各种手段，甚至社会工程学，并且面向二进制安全的攻击，无论 Rust 再怎么安全，也早已脱离其安全保障层面了。并且 xz 后门是针对底层操作系统诸如 Linux/Unix 的供应链攻击，Rust 开发者再怎么审查依赖的 crate 也不可能识别出这种后门。

虽然 Rust 语言对防范 xz 这类直接修改 .so 二进制文件的后门攻击有限，但 Rust 语言特性至少也能提升一下攻击者的门槛：

外部函数接口 (FFI) 的安全处理：Rust 通过其外部函数接口（FFI）提供了更严格的安全措施。虽然 Rust 允许通过unsafe代码块使用裸指针和直接内存操作，但它需要操作 C-ABI 时应该明确标记这些块为不安全，从而促使开发者在使用时更加谨慎，并进行更多的代码审查。
减少未定义行为：Rust 的设计旨在尽量减少未定义行为，这是 C 和 C++ 中常见的安全漏洞来源。例如，在 C/C++ 中，未初始化的变量或野指针可以被用来执行未授权代码或植入后门。Rust 的编译器会确保所有变量在使用前都已初始化，并且通过借用检查器防止悬挂指针和其他不安全的内存访问模式。
模块化和封装：Rust 强制实行模块化和良好的封装原则，这有助于隔离和限制代码的影响范围。在上文的后门分析中，后门通过篡改一小部分关键代码实现植入。Rust 通过私有性和封装，以及明确的模块边界，可以帮助限制潜在恶意代码的影响范围，使得未经授权的修改更加困难。
可审计性和透明性：Rust 的包管理器和构建系统（Cargo）提供了关于依赖和版本控制的清晰定义，使得从源码到构建的过程更加透明和可审计。这对于防止在依赖库中植入后门至关重要，因为它使得跟踪和验证所有使用的外部代码变得更加容易。
编译时保证：Rust 的编译器提供了多种安全检查，这些检查可以在编译时捕获潜在的危险操作，如不正确的内存访问模式、类型不匹配等。这增加了在代码达到生产环境之前捕获和修正问题的机会。

启示

xz 后门背后所用的技术表明，攻击者肯定是一个黑帽经验非常丰富的人或团伙。多亏了 Andres 这位英雄，才阻止了这次“核弹级”后门攻击。

可能有 75% 的人习惯使用curl > bash来安装最新和最好的开发工具。之前有 curl 曝出 0day （2023年10月），现在又遇到 xz 后门 bash 混淆技术提取后门。我不禁感慨，这个世界真是太危险了。

我们该如何应对这类「核弹级」攻击？

有人认为，检测比预防更有价值。应该在检测工具和手段上面加大投资。
在发行版中，每个补丁都应该经过深入讨论，特别是像 OpenSSH 这样的安全关键组件。如果 sshd 没有与之链接，整个 xz 的影响本可以减少很多。
xz 问题本质上是Linux和BSD发行商面临的一个运营问题，而不是开发问题。
开源社区的用户应该对那些免费的开源项目的作者自身的心理和经济状态有所关注，最起码要保证友好的交流，不要施加压力。

“

一位 FFmpeg 开源媒体软件包的开发者在推特上强调了这个问题，他说：“xz 事件显示了对无偿志愿者的依赖可能会导致重大问题。万亿美元的公司期望从志愿者那里获得免费和紧急的支持”，他们还提供了证据，指出他们如何处理影响微软 Teams 的“高优先级”错误。

虽然技术的黑暗面也有充满了智慧与技巧的一面，但我们不应该拿它来做恶。感谢阅读。

长亭百川云 - 文章详情

长亭百川云

【安全观察】xz 后门启示录

xz 后门事件的完整时间线

为什么说 xz 后门是「核弹级」后门

xz 后门实施的关键阶段分析

社会工程学：取得维护者信任

源码修改，构造后门

编译阶段的链接与混淆

修改 `.so`共享文件

后门是如何被发现的

Rust 语言能阻止 xz 后门级别的攻击吗？

启示

延伸阅读

【安全观察】xz 后门启示录

xz 后门事件的完整时间线

为什么说 xz 后门是「核弹级」后门

xz 后门实施的关键阶段分析

社会工程学：取得维护者信任

源码修改，构造后门

编译阶段的链接与混淆

修改 .so共享文件

后门是如何被发现的

Rust 语言能阻止 xz 后门级别的攻击吗？

启示

延伸阅读

修改 `.so`共享文件