1. Executive Summary

• CVEs about SQLite probably do not apply to your use of SQLite.

• All historical vulnerabilities reported against SQLite require at least one of these preconditions:

  1. The attacker can submit and run arbitrary SQL statements.

  2. The attacker can submit a maliciously crafted database file to the application that the application will then open and query.

• Few real-world applications meet either of these preconditions, and hence few real-world applications are vulnerable, even if they use older and unpatched versions of SQLite.

• The SQLite development team fixes bugs promptly, usually within hours of discovery. New releases of SQLite are issued if the bug seems likely to impact real-world applications.

• Grey-hat hackers are rewarded based on the number and severity of CVEs that they write. This results in a proliferation of CVEs that have minor impact, or no impact at all, but which make exaggerated impact claims.

• Very few CVEs written about SQLite are real vulnerabilities in the sense that they do not give any new capabilities to an attacker. Consider:

  1. Almost all CVEs written against SQLite require the ability to inject and run arbitrary SQL.

  2. The advertised consequence of most CVEs is "denial of service", typically by causing a crash through a NULL pointer dereference or a division by zero, or similar.

  3. But if an attacker can already run arbitrary SQL, they do not need a bug to cause a denial of service. There are plenty of perfectly legal and valid SQL statements that will consume unlimited CPU, memory, and disk I/O in order to create a denial-of-service without requiring help from bugs.

  4. Hence, the mere fact that an attacker has a way to inject and run arbitrary SQL is in and of itself a denial-of-service attack. That the arbitrary SQL might also tickle a bug in SQLite and cause a crash is not a new vulnerability.

• The SQLite developers do not write CVEs. Any CVEs you find on SQLite are generated by third-parties, often without any input from the core developers. A common scenario is that someone will report a bug in SQLite, which will promptly be fixed, then weeks later a CVE for that bug will appear, unbeknownst to the developers.

• You should not assume that a CVE about SQLite contains authoritative information. CVEs often contain inaccuracies. The SQLite developers have attempted to add clarifications and corrections to CVEs about SQLite.

2. About CVEs

CVEs ("Common Vulnerabilities and Exposures") are reports of software bugs that might allow a system to be hacked. The idea behind CVEs is sound. They provide a common naming scheme whereby software bugs that might compromise information security can be easily tracked.

While the original idea being CVEs is sound, the current processes for creating and managing CVEs are inadequate. There are countless grey-hat hackers running fuzzers against a wide-variety of open-source software products (SQLite as well as many others) and writing up CVEs against any problems they find. The grey-hats are rewarded, sometimes with prestige and sometimes financially, by the number and severity of the CVEs they write. This incentive results in a proliferation of CVEs which are often not well-vetted and which can have exaggerated impact claims. The quality-control procedures for CVEs are unable to cope with this flood of inputs, making it difficult to correct exaggerated, misleading, omitted, or inaccurate claims.

This is not to say that CVEs are useless. CVEs do still (mostly) report actual bugs. But in most cases the bugs are not true vulnerabilities, in the sense that they do not contribute to data loss or compromise in and of themselves. It is good that bugs are reported and fixed. But not every bug is accessible from every application. In the case of SQLite, most of the bugs reported by CVEs are inaccessible in most applications. Upgrading to the latest version of SQLite is always a good plan, but it need not be an emergency just because an anonymous grey-hat on the internet wrote up a CVE.

2.1. A separate SQL injection vulnerability is usually required

Other C-libraries that process complex structured inputs will routinely be asked to deal with unvetted inputs from untrusted sources. Libraries like libjpeg, or libzip, or OpenSSL are handed input streams that come directly from potentially hostile agents.

But database engines like SQLite are usually not this way. The SQL scripts that are passed into SQLite come from the (trusted) application itself, not from an attacker. Sometimes applications contain bugs by which an external attacker can trick the application into sending SQL of the attackers design into the database engine. This is a separate bug in the application called an SQL Injection vulnerability. Since SQL text is executable code, an SQL Injection vulnerability is actually a special case of a Remote Code Execution (RCE) vulnerability. An SQL Injection is perhaps not quite as bad as other kinds of RCEs because, while SQL is a powerful language, it is not as convenient for crafting an exploit as Python or shell script or raw machine code. Nevertheless, an SQL Injection is a serious problem.

Most CVEs written about SQLite assume that the attacker is able to run arbitrary SQL scripts in SQLite. In most applications, this means that there must first be an SQL Injection vulnerability that allows the attacker to inject the malicious SQL.

A few applications do allow untrusted SQL scripts received from potentially hostile agents to be run direct in SQLite. The main example of this is the Chrome and Safari web browsers, which allow an anonymous web page to run SQL using the WebSQL feature of Javascript. This is done inside a sandbox with tightly controlled constraints on resources, lest the SQL script try to soak up all available memory or CPU cycles in a denial-of-service attack. Chrome and Safari have the infrastructure in place to allow a hostile agent to run code which does not harm or compromise the rest of the machine. They have to, as they also run Javascript which could, if not tightly controlled, do even more damage than unrestrained SQL. Apart from Chrome and Safari, no applications known to the SQLite developers deliberately allows an anonymous remote agent to run arbitrary SQL text.

However, most CVEs written against SQLite flippantly assume that an attacker is free to run any arbitrary SQL in the database engine. So to a good approximation, this means most CVEs written against SQLite really only apply to SQLite as it is used in Chrome and Safari. Or, in other words, most CVEs for SQLite do not apply to you unless you are one of the developers of Chrome or Safari.

2.2. Defense Against Dark Arts

Most applications can use SQLite without having to worry about bugs in obscure SQL inputs. If the application controls the SQL, and the application is not deliberately trying to break SQLite, then everything should just work. It is not necessary to have the latest patched version of SQLite. Any older version should work just fine.

However, there are some occasions where an application does need to be able to safely run untrusted SQL. The SQLite developers work hard to make SQLite safe for this purpose, though there are occasional slip-ups. It is good to keep up-to-date with the latest patches in this case. The separate defense against dark arts document contains additional suggestions that can help prevent zero-day attacks in cases where SQLite is given inputs that come directly from untrusted sources.

2.3. The SQLite Developer Policy Toward CVEs

SQLite developers fix all bugs in SQLite as soon as they are reported, usually within a few hours. The fixes are immediately available on the public SQLite source tree. If a bug seems like it might cause problems for existing applications, a new patch release for SQLite will be issued.

However, the SQLite developers do not track CVEs. There are various reasons for this:

1. The developers often do not find out about CVEs until long after the bug is fixed. You can see this by the fact that many CVEs reference the bug fix in their initial report.

2. CVEs are a low-quality source of information about bugs in SQLite that are likely to affect most applications.

3. Almost all bugs reported by CVEs are just bugs and not true vulnerabilities. Claiming that they are vulnerabilities is stretching the meaning of the word "vulnerability" and the SQLite developers do not wish to participate in that deception.

4. The developers have no editorial influence on the content of CVEs, and they do not like to be controlled by groups in which they have no voice.

3. Status Of Recent SQLite CVEs

Though the SQLite developers do not consider CVEs to be a reliable source of information about bugs in SQLite, they recognize that many groups, and especially small teams working at the bottom of tall bureaucracies, sometimes need to track CVEs, whether they are useful or not. To aid in this chore, the following table of recent CVEs affecting SQLite is provided.

If you notice new CVEs associated with SQLite that are not in the table below, please bring them to the attention of the developers on the SQLite Forum so they can be added.