原本在写技术随笔，笔锋一转，写了点题外话，结果越写越多，遂成此文。

时至今日，fuzzing早已不再是单纯的fuzzing，程序分析和AI让fuzzing变得更加强大——当然，反过来也是这样。技术、学科和领域的交叉与融合总会带来令人耳目一新的效果。当下，LLM已经在fuzzing等信息安全领域展现出非凡的潜力（关于此，可以阅读我之前写的文献总结）。

2023年8月，Google在博客上发表了一篇文章，分享在“LLM辅助Fuzzing”上取得的进展，项目也已经在GitHub上开源。他们将LLM与始于2016年的OSS-Fuzz项目相结合，想要打造全自动化的工作流。不负众望，LLM生成的fuzzing target成功“重新”发现了包含CVE-2022-3602（来自OpenSSL项目）在内的漏洞，相关代码段之前从未被fuzzing覆盖过，表明LLM的合理使用确实能够提升fuzzing能力。在这篇博客的末尾，Google团队列出了令人心动的长远目标：

Our longer term goals include:

  • Adding LLM fuzz target generation as a fully integrated feature in OSS-Fuzz, with continuous generation of new targets for OSS-fuzz projects and zero manual involvement.
  • Extending support from C/C++ projects to additional language ecosystems, like Python and Java.
  • Automating the process of onboarding a project into OSS-Fuzz to eliminate any need to write even initial fuzz targets.

We’re working towards a future of personalized vulnerability detection with little manual effort from developers. With the addition of LLM generated fuzz targets, OSS-Fuzz can help improve open source security for everyone.

这也是无数信息安全从业者的愿景——如果完全自动化不会导致自己失业的话。然而，本文并不是一篇技术笔记，让我们暂时放下“如何更好地fuzzing”这个话题。

值得一提的是，OSS-Fuzz项目最初是作为对Heartbleed（CVE-2014-0160）漏洞的反应措施建立的。一方面，这个漏洞具有如下特征：存在于当时广泛使用的开源项目（OpenSSL）当中、后果严重、影响几乎每一个互联网用户；另一方面，它却又是一个简单的溢出漏洞，具有易被检测、易被利用的特点。Google认为，如果fuzzing在当时得到应用，Heartbleed本应被提前发现，损失会大大减少。OSS-Fuzz是一项免费服务，自动化运行开源项目的fuzzer，并向项目作者私下报告漏洞。开源项目作者要做的是向Google提出申请，并将自己的项目集成到OSS-Fuzz。客观来说，OSS-Fuzz为开源项目的安全性做出了很大贡献——截至2023年8月，它已经帮助1000多个项目发现并修复了超过10000个漏洞和36000个bug。

近期，xz项目投毒无疑是全世界信息安全领域最为关注的安全事件。Redhat为这个事件分配了漏洞编号CVE-2024-3094，CVSS评分为满分10.0。NVD中对此漏洞的描述如下：

Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library.

针对这次事件的技术分析尚未结束，它对世界的影响将会更加深远。如果攻击行动没有被发现、恶意代码被顺利分发部署到服务器上，后果将不堪设想，危害很可能超过前面提到的Heartbleed漏洞和2022年横扫无数服务器、客户端的Log4Shell漏洞（CVE-2021-44228，CVSS评分同样为10.0）。

事实上，OSS-Fuzz也与这起事件有关系，因为xz项目本身在OSS-Fuzz的fuzzing范围中。根据研究人员梳理出的xz事件时间线，在成为xz项目维护者之后，攻击者Jia Tan于2023年3月20日修改了xz项目的OSS-Fuzz配置文件，将自己设置为接收bug报告的主要联系人；他又在2023年7月7日声称xz项目引入的ifunc与-fsanitize=address不兼容，并主动禁用了OSS-Fuzz针对ifunc的fuzzing，这是Google发布那篇“LLM辅助Fuzzing”博客的一个月之前。

现实永远比电影更精彩。时间回到七年前，面对一个波及全网的严重漏洞，人们反省并建立了一套卓有成效的大规模fuzzing系统，只为让开源项目的开发者更早获得漏洞信息。谁能想到，若干年后，“开发者”这一角色本身却成为了恶意的源头。需要严肃声明的是，这里并非是对开源运动或开源项目开发者的指责。相反，我受益于并参与着开源运动，理解并尊重每一位认真的开发者。然而，问题是不容忽视的。Jia Tan用了两年时间，步步为营设下这样一个局，及时（真的吗？）发现确实是我们的幸运。这也许只是一个开始，甚至已经不是开始。

近年来，关于开源运动的局限性时有讨论——在软件供应链的依赖树上，某些关键节点被所有人使用却只有若干不堪重负、“用爱发电”的维护者时，这一定是有问题的——对于使用者和开发者双方而言。就其中的安全问题来说，一个可能的解决思路是采用类似Zero Trust和Trusted Computing这样的方案，始终验证，从不信任。然而话说回来，xz事件的曝光本身就源自微软工程师对“性能异常”的追根溯源，而非安全相关的检测。那么我们又是否做好了准备，去接入一个为了安全大幅抬升成本的赛博世界？