*** DRAFT ***
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:
The attacker can submit and run arbitrary SQL statements.
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:
Almost all CVEs written against SQLite require the ability to inject and run arbitrary SQL.
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.
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.
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.
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.
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.
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.
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:
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.
CVEs are a low-quality source of information about bugs in SQLite that are likely to affect most applications.
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.
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.
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.
| CVE Number | Fix | Comments |
|---|---|---|
| CVE-2022-46908 | Bug not in the SQLite library | This is a bug in the --safe command-line option of the command-line shell program that is available for accessing SQLite database files. The bug does not exist in the SQLite library. Nor is it an issue for the CLI as long as the user does not depend on the --safe option. It is not serious. It is debatable whether or not this is a security issue. |
| CVE-2022-38627 | Not a bug | This is not a bug in SQLite. This is an SQL injection bug in a specific PHP application. In other words, the bug is in the PHP application code, not in SQLite. Even though this CVE is not about SQLite, "SQLite" is mentioned in the publicity about the bug and so we list it here. |
| CVE-2022-35737 | 3.39.2 (2022-07-21) |
This bug is an array-bounds overflow. The bug is only accessible when using some of the C-language APIs provided by SQLite. The bug cannot be reached using SQL nor can it be reached by providing SQLite with a corrupt database file. The bug only comes up when very long string inputs (greater than 2 billion bytes in length) are provided as arguments to a few specific C-language interfaces, and even then only under special circumstances. |
| CVE-2022-24854 | Not a bug | This CVE describes a bug in an application that uses SQLite, not in SQLite itself. SQLite is doing everything correctly. The application grants users the ability to run SQL statements, using SQLite, that can leak or change information that those users should not normally have access to. This is purely an application bug. It does not describe a malfunction or vulnerability in SQLite. |
| CVE-2022-21227 | Not a bug | This CVE describes a bug in a third-party packages that provides a binding for SQLite to Node.js. The bug reported is in the third-party Node.js binding, not in SQLite itself. Do not be confused by the use of the word "SQLite" in the ambiguously-worded CVE description. |
| CVE-2021-45346 | Not a bug | This CVE is misinformation. See the discussion around SQLite forum post 53de8864ba114bf. |
| CVE-2021-42169 | Not a bug | This CVE has nothing whatsoever to do with SQLite. It is about a bug in application that happens to use SQLite. Since SQLite is mentioned in the CVE description, the CVE is included here to emphasize that this is not an SQLite bug. |
| CVE-2021-36690 | Bug not in the SQLite library | This bug is not in the SQLite core library, but rather in an experimental extension that is used to implement the .expert command in the CLI. The code that contains the bug does not appear in standard SQLite builds, though it is included in the sqlite3.exe command-line tool. Applications must link against the extra source code files that implement the extension and take other deliberate actions to activate the extension before the troublesome code can be run. For the rare application that uses the troublesome extension, the consequence of this bug is that malicious SQL can cause a NULL pointer deference and denial of service. (details) |
| CVE-2021-28305 | Not a bug | This is not a bug in SQLite. The bug is in a third-party application that uses SQLite. SQLite is mentioned by name in the CVE description, however, so we have included the CVE in the list. |
| CVE-2021-23404 | Not a bug | This is not a bug in SQLite. The bug is in a third-party application that uses SQLite and includes "sqlite" in its name. This CVE is included on the list because it mentions SQLite even though the bug has nothing to do with SQLite. |
| CVE-2021-20227 | 3.34.1 (2021-01-20) |
Malicious SQL statement causes read-after-free. No harm can come of this particular read-after-free instance, as far as anyone knows. The bug is undetectable without a memory sanitizer. The CVE claims that this bug is an RCE - a Remote Code Execution vulnerability, but that claim is incorrect. The RCE claim is misinformation. (details) |
| CVE-2021-20223 | 3.34.0 (2020-12-01) |
The problem identified by this CVE is not a vulnerability. It is a malfunction. A coding error causes FTS5 to sometimes return inconsistent and incorrect results under obscure circumstances, but no memory errors occur. (details) |
| CVE-2020-15358 | 3.32.3 (2020-06-18) |
Malicious SQL statement causes an read past the end of a heap buffer. (details) |
| CVE-2020-13871 | 3.32.3 (2020-06-18) |
Malicious SQL statement causes a read-only use-after-free memory error. (details) |
| CVE-2020-13632 | 3.32.0 (2020-05-22) |
Malicious SQL statement causes a read of a NULL pointer in the matchinfo() SQL function of the FTS3 extension, resulting in denial of service. (details) |
| CVE-2020-13631 | 3.32.0 (2020-05-22) |
Malicious SQL statement (an ALTER TABLE that tries to rename a virtual table into one of its own shadow tables) causes an infinite loop and denial of service. (details) |
| CVE-2020-13630 | 3.32.0 (2020-05-22) |
Malicious SQL statement causes a read-only use-after-free, possibly resulting in a incorrect output from the snippet() SQL function of the FTS3 extension. There is no known way to exfiltrate data or crash the application using this bug. (details) |
| CVE-2020-13435 | 3.32.1 (2020-05-25) |
Malicious SQL statement causes a read access to a NULL pointer and denial of service. (details) |
| CVE-2020-13434 | 3.32.1 (2020-05-25) |
Malicious SQL statement involving the printf() SQL function results in an integer overflow which can overwrite the stack with over 2 billion bytes of 0x30 or 0x20 (ASCII '0' or ' '). Even though this is a stack overwrite, there is no known way to redirect control or otherwise escalate the level of harm. This is a denial-of-service attack only. (details) |
| CVE-2020-11656 | 3.32.0 (2020-05-22) |
Malicious SQL statement causes read-only use-after-free of memory allocation if SQLite is compile with -DSQLITE_DEBUG. Does not affect release builds. (details) |
| CVE-2020-11655 | 3.32.0 (2020-05-22) |
Malicious SQL statement causes a read using an uninitialized pointer and denial-of-service. (details) |
| CVE-2020-9327 | 3.32.0 (2020-05-22) |
Malicious SQL statement causes a read using an uninitialized pointer and denial-of-service (details) |
| CVE-2020-6405 | 3.31.0 (2020-01-22) |
Malicious SQL statement causes a NULL pointer dereference and denial-of-service (details) |
| CVE-2019-20218 | 3.31.0 (2020-01-22) |
Malicious SQL statement causes an uninitialized pointer read and denial-of-service. (details) |
| CVE-2019-19959 | 3.31.0 (2020-01-22) |
Malicious SQL statement causes a NULL pointer dereference in the Zipfile virtual table extension and denial-of-service. This is only possible when the optional Zipfile virtual table extension is deployed, which is not the case in default builds. (details) |
| CVE-2019-19926 | 3.31.0 (2020-01-22) |
Malicious SQL statement causes an uninitialized pointer read and denial-of-service. (details) |
| CVE-2019-19925 | 3.31.0 (2020-01-22) |
Malicious SQL statement causes a NULL pointer dereference and in the Zipfile virtual table extension and denial-of-service. This is only possible when the optional Zipfile virtual table extension is deployed, which is not the case in default builds. (details) |
| CVE-2019-19924 | 3.31.0 (2020-01-22) |
Malicious SQL statement causes a uninitialized pointer reference and denial-of-service. (details) |
| CVE-2019-19923 | 3.31.0 (2020-01-22) |
Malicious SQL statement causes a NULL pointer dereference and denial-of-service. (details) |
| CVE-2019-19646 | 3.31.0 (2020-01-22) |
The PRAGMA integrity_check command might cause the byte-code for a prepared statement to loop indefinitely. This might enable a denial-of-service, if the application has not taken appropriate and prudent steps to limit the run-time of SQL statements. This is not a vulnerability, as there are countless perfectly valid SQL queries, especially queries involving recursive common table expressions, that also run essentially forever. (details) |
| CVE-2019-19317 | 3.31.0 (2020-01-22) |
This CVE identifies a bug in a development check-in of SQLite. The bug never appeared in any official SQLite release. (details) |
This page last modified on 2023-01-02 14:22:42 UTC
*** DRAFT ***