不靠编译器的「信任信任」攻击：被篡改的 strip 污染整个发行版

当天发生了什么

2026-07-27 12:59（UTC），论文《Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation》v1 提交到 arXiv。作者挑战了「Thompson 的信任信任攻击只针对编译器」的看法，围绕 GNU strip 实现了完整攻击。strip 既不检查也不生成源代码，攻击只通过操纵已构建的 ELF 二进制完成。在 NixOS 的引导过程中，二进制种子里一个被篡改的 strip 把载荷传给下一代 strip，即使种子离开依赖闭包后仍能保留到最终标准环境。在一个真实的 nixpkgs 版本上，攻击成功构建了完整的图形安装镜像，并在其中几乎所有二进制中植入后门。

与应用加固流程的关系

这篇论文与应用保护的关系比表面上更紧密。许多加固流程正是在编译之后对二进制做变换：剥离符号、重写段、插入校验、混淆、重新签名。这些工具和 strip 一样，处在「看不到源码、却决定最终产物内容」的位置。如果其中任何一个被替换或篡改，源码审查和代码签名都无法发现问题，因为签名只证明产物来自你的流水线，而不是证明产物与源码一致。因此，引入二进制变换工具在提高逆向成本的同时，也扩大了需要信任的范围，应当用同样严格的供应链措施来管理。

可以做的检查

第一，列出构建链中所有在编译后修改二进制的工具（strip、链接后优化、混淆器、加壳与签名工具），记录版本和来源，并对下载的工具包核对哈希或签名。第二，尽可能让构建可复现：在两个独立环境中构建同一提交，比较未签名产物是否一致，并调查差异。第三，对加固后的产物保留变换前的版本，定期比较两者的导出符号、段结构和行为测试结果，确认变换只做了预期的事情。

行动清单

• 列出并校验所有编译后修改二进制的工具
• 在两个独立环境中复现构建并比较未签名产物
• 保留变换前产物并定期比对结构与行为