1.执行摘要

• 有关SQLite的CVE可能不适用于您使用SQLite的情况。

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

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

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

• 很少有现实世界的应用程序可以满足这两个先决条件，因此，即使它们使用较旧且未修补的SQLite版本，也很少有现实世界的应用程序易受攻击。

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

• 黑客会根据他们编写的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开发人员试图对CVE添加关于SQLite的说明和更正，但没有成功。

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 Web浏览器，它们允许匿名网页使用Javascript的WebSQL功能运行SQL。这是在对资源进行严格控制的沙箱中完成的，以免SQL脚本试图在拒绝服务攻击中吸收所有可用的内存或CPU周期。Chrome和Safari具有适当的基础结构，允许恶意代理运行不会损害或损害计算机其余部分的代码。他们必须，因为他们还运行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中有关bug的可靠信息来源，但他们认识到许多小组，尤其是在高层官僚机构底层的小型团队，有时仍需要跟踪CVE，无论它们是否有用。为了帮助完成这项工作，下表提供了影响SQLite的近期CVE。

如果您发现下表中没有列出与SQLite相关的新CVE，请在SQLite论坛上引起开发人员的注意，以便可以添加它们。