一、执行摘要

• 关于 SQLite 的 CVE 可能不适用于您对 SQLite 的使用。

• 针对 SQLite 报告的所有历史漏洞至少需要以下先决条件之一：

  1. 攻击者可以提交并运行任意 SQL 语句。

  2. 攻击者可以向应用程序提交恶意制作的数据库文件，然后应用程序将打开并查询该文件。

• 很少有现实世界的应用程序满足这些先决条件，因此很少有现实世界的应用程序容易受到攻击，即使它们使用较旧且未打补丁的 SQLite 版本。

• SQLite 开发团队会及时修复错误，通常是在发现错误后的数小时内。如果错误似乎可能影响实际应用程序，则会发布新版本的 SQLite。

• 灰帽黑客根据他们编写的 CVE 的数量和严重程度获得奖励。这导致 CVE 的激增，这些 CVE 的影响很小，或者根本没有影响，但却夸大了影响声明。

• 很少有关于 SQLite 的 CVE 是真正的漏洞，因为它们不会为攻击者提供任何新功能。考虑：

  1. 几乎所有针对 SQLite 编写的 CVE 都需要能够注入和运行任意 SQL。

  2. 大多数 CVE 的广告后果是“拒绝服务”，通常是通过 NULL 指针取消引用或除以零或类似方式导致崩溃。

  3. 但是，如果攻击者已经可以运行任意 SQL，他们就不需要错误来导致拒绝服务。有大量完全合法且有效的 SQL 语句会消耗无限的 CPU、内存和磁盘 I/O，以便在不需要错误帮助的情况下创建拒绝服务。

  4. 因此，攻击者有办法注入和运行任意 SQL 这一事实本身就是拒绝服务攻击。任意 SQL 也可能触发 SQLite 中的错误并导致崩溃，这并不是一个新漏洞。

• SQLite 开发人员不编写 CVE。您在 SQLite 上找到的任何 CVE 都是由第三方生成的，通常没有来自核心开发人员的任何输入。一个常见的场景是有人会报告 SQLite 中的错误，该错误会立即得到修复，然后几周后该错误的 CVE 就会出现，而开发人员并不知道。

• 您不应假设有关 SQLite 的 CVE 包含权威信息。CVE 通常包含不准确的信息。SQLite 开发人员已尝试向有关 SQLite 的 CVE 添加说明和更正。

2.关于 CVE

CVE（“常见漏洞和暴露”）是可能允许系统被黑客攻击的软件错误报告。CVE 背后的想法是合理的。它们提供了一个通用的命名方案，可以很容易地跟踪可能危及信息安全的软件错误。

虽然 CVE 的最初想法是合理的，但当前创建和管理 CVE 的流程并不充分。有无数的灰帽黑客对各种各样的开源软件产品（SQLite 以及许多其他产品）运行模糊测试，并针对他们发现的任何问题编写 CVE。灰帽子们会根据他们编写的 CVE 的数量和严重程度来获得回报，有时是声望，有时是经济上的回报。这种激励导致 CVE 激增，这些 CVE 通常没有经过充分审查，并且可能会夸大其影响声明。CVE 的质量控制程序无法应对大量输入，因此很难纠正夸大、误导、遗漏或不准确的声明。

这并不是说 CVE 没有用。CVE 仍然（大部分）报告实际的错误。但在大多数情况下，错误并不是真正的漏洞，因为它们本身不会导致数据丢失或危害。报告并修复错误是件好事。但并非每个应用程序都可以访问每个错误。就 SQLite 而言，CVE 报告的大多数错误在大多数应用程序中都无法访问。升级到最新版本的 SQLite 始终是一个好计划，但不必因为互联网上的匿名灰帽编写了 CVE 而紧急。

2.1. 通常需要单独的 SQL 注入漏洞

其他处理复杂结构化输入的 C 库通常会被要求处理来自不受信任来源的未经审查的输入。libjpeg、libzip 或 OpenSSL 等库是直接来自潜在敌对代理的输入流。

但是像 SQLite 这样的数据库引擎通常不是这样的。传递到 SQLite 的 SQL 脚本来自（受信任的）应用程序本身，而不是来自攻击者。有时应用程序包含错误，外部攻击者可以通过这些错误诱使应用程序将攻击者设计的 SQL 发送到数据库引擎中。这是应用程序中的一个单独错误，称为 SQL 注入漏洞。由于 SQL 文本是可执行代码，因此 SQL 注入漏洞实际上是远程代码执行 (RCE) 漏洞的特例 . SQL 注入可能不像其他类型的 RCE 那样糟糕，因为虽然 SQL 是一种功能强大的语言，但它不像 Python 或 shell 脚本或原始机器代码那样方便地制作漏洞。然而，SQL 注入是一个严重的问题。

大多数关于 SQLite 的 CVE 都假设攻击者能够在 SQLite 中运行任意 SQL 脚本。在大多数应用程序中，这意味着首先必须存在允许攻击者注入恶意 SQL 的 SQL 注入漏洞。

一些应用程序确实允许从潜在敌对代理接收的不受信任的 SQL 脚本直接在 SQLite 中运行。这方面的主要示例是 Chrome 和 Safari 网络浏览器，它们允许匿名网页使用 Javascript 的 WebSQL 功能运行 SQL。这是在严格控制资源限制的沙箱内完成的，以免 SQL 脚本试图在拒绝服务攻击中吸收所有可用内存或 CPU 周期。Chrome 和 Safari 拥有适当的基础设施，允许恶意代理运行不会损害或危及机器其余部分的代码。他们必须这样做，因为他们还运行 Javascript，如果不严格控制，Javascript 可能比不受限制的 SQL 造成更大的损害。除了 Chrome 和 Safari，

然而，大多数针对 SQLite 编写的 CVE 轻率地假设攻击者可以在数据库引擎中自由运行任何任意 SQL。因此，大致而言，这意味着大多数针对 SQLite 编写的 CVE 实际上只适用于 SQLite，因为它在 Chrome 和 Safari 中使用。或者，换句话说，除非您是 Chrome 或 Safari 的开发人员之一，否则 SQLite 的大多数 CVE 不适用于您。

2.2. 黑魔法防御术

大多数应用程序都可以使用 SQLite 而不必担心模糊的 SQL 输入中的错误。如果应用程序控制 SQL，并且应用程序没有故意破坏 SQLite，那么一切都应该正常工作。没有必要安装最新的 SQLite 补丁版本。任何旧版本都应该可以正常工作。

但是，在某些情况下，应用程序确实需要能够安全地运行不受信任的 SQL。SQLite 开发人员为此目的努力使 SQLite 安全，尽管偶尔会出现失误。在这种情况下，最好及时更新最新的补丁。单独的黑科技防御文档包含额外的建议，在 SQLite 的输入直接来自不受信任的来源的情况下，这些建议可以帮助防止零日攻击。

2.3. 针对 CVE 的 SQLite 开发人员政策

SQLite 开发人员在收到报告后立即修复 SQLite 中的所有错误，通常在几个小时内。这些修复程序可立即在 公共 SQLite 源代码树上获得。如果一个错误看起来可能会导致现有应用程序出现问题，则会发布一个新的 SQLite 补丁版本。

但是，SQLite 开发人员不跟踪 CVE。这有多种原因：

1. 开发人员通常在错误修复很久之后才发现 CVE。您可以从许多 CVE 在其初始报告中引用错误修复这一事实中看出这一点。

2. CVE 是有关 SQLite 中可能影响大多数应用程序的错误的低质量信息来源。

3. 几乎所有 CVE 报告的错误都只是错误，而不是真正的漏洞。声称它们是漏洞是在夸大“漏洞”这个词的含义，SQLite 开发人员不希望参与这种欺骗。

4. 开发人员对 CVE 的内容没有编辑影响，他们不喜欢被没有发言权的团体控制。

3.最近 SQLite CVE 的状态

尽管 SQLite 开发人员并不认为 CVE 是有关 SQLite 错误信息的可靠来源，但他们认识到许多团体，尤其是在高层官僚机构底层工作的小团队，有时需要跟踪 CVE，无论它们是否有用. 为了帮助完成这项工作，下表提供了最近影响 SQLite 的 CVE。

如果您发现与 SQLite 相关的新 CVE 未在下表中列出，请将它们告知SQLite 论坛上的开发人员，以便将其添加。