文章认为CVE-2024-3094漏洞的真正根源不应归咎于xz-utils，而是两个长期存在的开源软件设计决策：OpenSSH与SystemD的链接以及GNU IFUNC功能的存在。作者指出这些设计缺陷使得攻击成为可能，而大部分分析过度关注了恶意代码如何进入xz-utils仓库。

标题：GNU IFUNC才是CVE-2024-3094漏洞的真正元凶

主要内容：

1. 漏洞背景

   • CVE-2024-3094（xz-utils后门事件）是全球网络安全领域一次惊险的未遂攻击
   • 若非Andres Freund及时发现，全球多数SSH服务器可能已向攻击者开放root权限
   • 现有分析过度聚焦恶意代码如何进入xz-utils仓库，而忽视了两个关键设计决策：
     • OpenSSH与SystemD的链接
     • GNU IFUNC的存在

2. 技术根源分析

   • Linux发行版修改OpenSSH的原因：
     • OpenSSH由OpenBSD社区开发，Linux发行版需通过Portable OpenSSH项目进行适配
     • Fedora和Debian为修复sshd重启的竞态条件，自行维护SystemD补丁
   • 系统组件间的沟通断层：
     • 各开发团队（OpenSSH、SystemD、xz-utils）缺乏协同
     • 开源软件的"各自为政"特性导致关键设计假设（如动态链接）被破坏

3. GNU IFUNC机制剖析

   • 设计初衷：运行时选择最优函数实现（如根据CPU特性选择算法）
   • 安全隐患：
     • 允许在动态链接阶段执行任意代码
     • 破坏RELRO（只读重定位）安全机制
     • 文档匮乏且存在大量边界案例，GCC开发者称其"是个错误"

4. 替代方案对比

   • 全局函数指针：性能接近IFUNC且更安全
   • LD_PRELOAD：通过环境变量选择优化库
   • 多版本二进制分发：根据CPU特性打包不同实现
   • 性能测试显示IFUNC优势有限：在20亿次调用测试中，IFUNC耗时比函数指针多约47%

5. 结论建议

   • IFUNC应默认禁用，启用需显式使用警告性标志（如--enable-cve-2024-3094）
   • 除glibc外，其他软件使用IFUNC需提供充分理由
   • 现有替代方案在安全性、可维护性方面更具优势

关键图表说明： 1. OpenSSH供应链示意图展示从OpenBSD到各Linux发行版的代码流转路径 2. IFUNC工作原理示例：通过CPU检测选择不同函数实现 3. 性能对比数据表显示不同技术方案的执行耗时差异

（注：原文中的表情包图片链接和部分技术细节示例已精简，保留核心论证逻辑和关键数据）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

1. Linux发行版修改OpenSSH的争议

   • 观点1：认为OpenBSD开发者不关心Linux社区的说法是错误的，他们维护了可移植版本且systemd是可选的。
     引用："If they didn't care about the Linux community they wouldn't develop this software *for free"*
     引用："It's not the OpenBSD developers' fault some Linux distros use overly complex plumbing"
   • 观点2：指责Linux发行版自身因复杂性和补丁管理问题导致漏洞（如xz后门）。
     引用："The xz backdoor was a *Debian and Red Hat issue"*

2. IFUNC安全性的争论

   • 批评IFUNC：认为其削弱了RELRO（只读重定位）安全性，且存在替代方案。
     引用："IFUNC is hardly the only way to run code before main"
     引用："function pointers aren't great for security unless... explicitly make the memory unwritable"
   • 反驳IFUNC是主因：攻击者通过任意库代码即可达成目标，IFUNC并非关键问题。
     引用："IFUNC was not required... The game was lost as soon as the attacker had arbitrary code"
     引用："There are thousands of potential routes... we simply can't defend from all"

3. 其他技术观点

   • 动态链接的模块化设计（如PAM）被批评为脆弱，而OpenBSD的bsdauth因进程级模块化受推崇。
     引用："pam... hard to understand, hard to debug... bsdauth is possible for mere mortals to debug"
   • C++全局构造函数和Unicode标识符也被提及为潜在安全风险。
     引用："C++ allows running arbitrary code before *main... Does it bring security risks?"*

4. 根本原因分析

   • 部分评论认为漏洞是流程失败（如维护者审查缺失）而非技术问题。
     引用："a series of blatant process failures... IFUNC also bad"
   • 标题被指夸大，认为攻击者控制库内容后任何防护机制均无效。
     引用："No one should think that any relro... is going to deter anyone who can control the libraries"

总结：争议集中在Linux发行版维护责任、IFUNC的安全影响及攻击路径多样性上，多数人认为根本原因是流程漏洞而非单一技术缺陷。