💻 computer science

Vulnerability Abundance: A formal proof of infinite vulnerabilities in code

该论文通过构造性证明展示了单个 C 程序可包含无限多个可分配 CVE 的独立漏洞，进而提出了“漏洞丰度”这一量化概念，以区分无限漏洞集合与有限利用实例，并强调其在漏洞预防与网络风险分析中的理论及实践价值。

原作者： Eireann Leverett, Jeroen van der Ham-de Vos

发布于 2026-04-10

📖 1 分钟阅读☕ 轻松阅读

原作者： Eireann Leverett, Jeroen van der Ham-de Vos

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文提出了一個非常有趣且令人震惊的观点：软件漏洞的数量在理论上是无限的。

为了让你轻松理解，我们可以把这篇论文想象成一位科学家造了一台“漏洞制造机”，并证明了这台机器可以永远不停地生产出新的、独一无二的漏洞。

以下是用通俗语言和生动比喻对这篇论文核心内容的解读：

1. 核心实验：漏洞工厂 (The Vulnerability Factory)

想象一下，你有一台神奇的机器（论文里叫“漏洞工厂”），它是一小段 C 语言代码。

它是怎么工作的？这台机器有一个计数器（比如 1, 2, 3...）。每当你按一次启动键，它就会根据当前的数字，生成一个新的、微小的软件模块。
它生成了什么？每个模块里都藏着几个经典的“安全漏洞”（比如缓冲区溢出、格式字符串错误等）。
关键点：虽然漏洞的类型是一样的（比如都是“缓冲区溢出”），但因为计数器在变，每个模块里的漏洞具体参数都不同。
- 比喻： 就像你有一台 3D 打印机，它永远在打印“有瑕疵的杯子”。第 1 个杯子的瑕疵在杯底，第 2 个在杯壁，第 3 个在杯口。虽然它们都是“有瑕疵的杯子”，但每一个瑕疵的位置和大小都不同，所以每一个都是独一无二的。

2. 数学证明：为什么是无限的？

论文用数学集合论证明了：

因为计数器可以一直加下去（1, 2, 3... 直到无穷大），所以这台机器可以生成无穷多个不同的软件模块。
因为每个模块里的漏洞参数都不同，根据国际通用的漏洞编号规则（CVE），每一个都需要一个独立的身份证（CVE 编号）。
结论：只要机器不停，漏洞的数量就是可数无穷大（Countably Infinite）。就像自然数（1, 2, 3...）是无穷的一样，漏洞也是无穷多的。

3. 一个重要的区分：漏洞 vs. 利用 (Exploits)

这是论文最精彩的部分之一。作者打了一个非常棒的比方：

漏洞 (Vulnerabilities) 就像化学元素。宇宙中有无数种可能的元素组合，或者像化学元素周期表，虽然元素种类有限，但组合方式无穷无尽。
利用 (Exploits) 就像工业产品。虽然元素无穷多，但真正被大规模制造、用来赚钱或打仗的产品（比如手机、汽车）只有那么几种。

现实情况是：

虽然漏洞有无穷多，但黑客真正去开发“利用代码”（Exploit）去攻击的，可能不到 6%。
比喻： 就像大海里有无穷无尽的水滴（漏洞），但只有少数几条河流（利用代码）在流动。黑客不会去攻击每一滴水，他们只攻击那些流量最大、最容易到达的河流。

4. 新概念：漏洞丰度 (Vulnerability Abundance)

作者提出了一个新概念，叫“漏洞丰度”，这就像天文学家研究“元素丰度”（比如宇宙中氢最多，氧其次）。

语言决定命运：不同的编程语言就像不同的“恒星核聚变”过程，会产生不同种类的“元素”（漏洞）。
- C/C++（像氢炉）容易产生内存破坏类漏洞（如缓冲区溢出），就像宇宙中氢最多一样，这类漏洞在 C 语言里也最多。
- Rust/Java（像重元素炉）虽然消除了内存漏洞，但会产生逻辑错误或注入攻击，就像宇宙中重元素虽然少但依然存在。
动态变化：随着大家从 C 语言转向 Rust 或 Python，整个软件世界的“漏洞元素分布”也会发生变化。

5. 这对我们意味着什么？

不要试图“修完”所有漏洞：既然漏洞是无穷多的，试图找到并修补每一个漏洞就像试图把大海里的水舀干一样，是徒劳的（西西弗斯式的劳动）。
关注“市场占比”：真正的风险不在于漏洞有多少，而在于有多少人在用这个软件。
- 比喻： 如果一个漏洞只存在于一个只有 10 个人用的冷门软件里，它几乎没威胁。但如果一个漏洞存在于 Windows 或 Android 这种几十亿人用的系统里，哪怕只有一个漏洞，也是巨大的灾难。
未来的方向：我们不应该只盯着“发现了多少个漏洞”，而应该研究“漏洞的分布规律”。通过改变编程语言的选择、优化软件架构，我们可以改变“漏洞元素”的丰度，让危险的漏洞变少，让安全的漏洞变多。

总结

这篇论文告诉我们：

漏洞是无穷无尽的，就像自然数一样，你数不完。
但这不可怕，因为黑客只会攻击那些最流行、最容易下手的目标。
我们的策略应该是：不要试图消灭所有漏洞（因为不可能），而是要改变土壤（编程语言和架构），让危险的“漏洞元素”变得稀少，同时警惕那些占据巨大市场份额的“超级软件”。

这就好比我们无法消灭宇宙中所有的尘埃，但我们可以选择住在没有沙尘暴的地方，或者穿上更坚固的防护服。

这篇论文《Vulnerability Abundance: A formal proof of infinite vulnerabilities in code》（漏洞丰度：代码中无限漏洞的形式化证明）由 E. Leverett 和 J. van der Ham-de Vos 撰写，旨在通过构造性证明解决软件漏洞是“有限”还是“无限”的长期争论，并引入“漏洞丰度”这一新概念来量化漏洞的分布。

以下是该论文的详细技术总结：

1. 研究问题 (Problem)

核心争论：软件漏洞在本质上是稀疏的（Sparse，即发现并修复一个就能显著降低风险）还是稠密的（Dense，即漏洞数量近乎无限，修复单个意义不大）？
现有局限：之前的讨论多基于复杂性理论（如停机问题、Rice 定理）推测漏洞可能是无限的，或者基于经验数据（如 OpenBSD 代码库研究）观察漏洞发现率的变化，但缺乏一个明确的、可执行的构造性证明来证实无限漏洞的存在。
现实挑战：如果漏洞是无限的，传统的“发现 - 修复”补丁策略是否可行？如何量化漏洞的分布以指导安全投资？

2. 方法论 (Methodology)

论文采用构造性证明（Constructive Proof）结合形式化方法和集合论：

**构造“漏洞工厂” **(The Vulnerability Factory)：
- 作者编写了一个名为 vuln_factory.c 的 622 行 C 程序。
- **基础集 **(Base Set)：包含 11 个预定义的、来自不同 CWE 类别的经典漏洞（如栈溢出、堆溢出、格式字符串等）。
- **生成器 **(Generator)：程序维护一个持久计数器 $n$ 。每次运行时，它读取 $n$ ，生成一个新的 C 源文件 vuln_module_n.c，其中包含 5 个参数化的漏洞实例（例如缓冲区大小设为 $16+n$ ，整数溢出阈值设为 $INT\_MAX - n$ ）。
- 编译与迭代：生成的模块被编译为独立的共享库，计数器 $n$ 递增。
形式化验证：
- 集合论证明：定义漏洞为元组 $(c, t, p)$ （组件、类型、参数）。证明生成的漏洞集合 $V$ 与自然数集 $\mathbb{N}$ 存在双射，因此是可数无限（Countably Infinite）的。
- CVE 规则验证：依据 MITRE 的 CVE 计数规则，证明每个生成的模块都是独立的组件，且参数不同导致修复方案独立，因此每个实例都应分配独立的 CVE ID。
- 图灵机表征：将“漏洞工厂”抽象为图灵机，证明漏洞生成过程是可计算的，且任何图灵完备的系统都能实现类似的生成机制。
- 模型检测：使用 CTL（计算树逻辑）表达“漏洞数量有界”的安全属性，模型检测器能生成反例路径，证明对于任意有限界限 $C$ ，系统都能突破该界限。

3. 关键贡献 (Key Contributions)

构造性证明无限漏洞：首次通过一个具体的、可运行的 C 程序（漏洞工厂），严格证明了单个程序可以容纳可数无限个独立的、可分配 CVE 的漏洞。
形式化与通用性：将漏洞生成机制形式化为图灵机，证明这是计算系统的结构性属性，而非特定语言的边缘情况。该程序可作为未来漏洞理论研究的“测试对象”（Test Object）。
**引入“漏洞丰度” **(Vulnerability Abundance)：
- 类比化学元素丰度（Elemental Abundance），提出漏洞丰度概念，用于描述漏洞类型在软件语料库中的比例分布。
- 指出不同编程语言（如 C/C++ vs. Rust/Java）决定了“漏洞元素”的生成谱系（例如内存不安全语言产生内存破坏漏洞，安全语言产生逻辑或注入漏洞）。
区分“无限漏洞”与“有限利用”：
- 明确区分漏洞数量（无限）与实际被利用的漏洞（有限，实证数据显示仅约 6% 的 CVE 被利用）。
- 提出利用暴露度（Exploitation Exposure）模型： $E = A \times D \times P$ （丰度 $\times$ 部署份额 $\times$ 利用概率）。
解决“稠密 vs. 稀疏”争论：结论是漏洞在数量上是稠密（无限）的，但在利用上是稀疏的。风险取决于漏洞丰度与软件部署市场份额的相互作用。

4. 主要结果 (Results)

定理 4.4：漏洞工厂生成的漏洞集合 $V$ 是可数无限的，且每个元素都符合 CVE 分配标准。
鲁棒性分析：即使移除部分漏洞类型（如某类 CWE 被证明不产生独立 CVE），只要剩余类型数量大于 0，无限性依然成立。
图灵机结论：任何图灵完备系统都可以实现漏洞生成，这意味着无限漏洞是计算本质的属性。
实证数据支持：引用数据表明，尽管漏洞数量激增（年增长率 38%-61%），但实际被利用的比例极低（<6%），且利用频率高度依赖于受影响软件的市场份额（Monoculture effect）。
推论：没有任何有限规模的漏洞数据库能声称是“完整”的。

5. 意义与影响 (Significance)

理论意义：
- 终结了关于漏洞是否无限的哲学争论，提供了数学上的确定性。
- 为漏洞理论提供了新的基础工具（漏洞工厂），可用于测试扫描工具、形式化验证工具的极限（证明无法在有限时间内扫描完所有漏洞）。
实践意义：
- 安全策略转变：从试图“修复所有漏洞”（不可能）转向管理“漏洞丰度”和“部署风险”。
- 投资导向：安全资源应优先投向高丰度漏洞类型（如 C/C++ 中的内存安全问题）和高市场份额的软件组件。
- 语言选择：编程语言的选择直接决定了漏洞的“元素谱系”。迁移到内存安全语言（如 Rust）可以消除特定类别的无限漏洞，但需警惕其他类别的漏洞（如逻辑错误、注入）。
- 风险评估：结合漏洞丰度和市场份额，可以更准确地预测系统性风险。少数几个针对主流平台的利用代码即可覆盖大部分风险面（小利用原则）。

总结

这篇论文通过一个巧妙的构造性证明，揭示了软件漏洞在理论上的无限性，并提出了“漏洞丰度”这一新范式。它告诫安全界：面对无限的漏洞海洋，单纯的数量统计已无意义，关键在于理解漏洞的分布规律（丰度）以及它们如何与现实的软件部署（市场份额）相互作用，从而制定更有效的防御和风险管理策略。