Alessandro Bonazzi 5c7aa8c1c0 Patch level : 12.0 no-patch
Files correlati     :
Commento            :

Aggiunta documentazione di sqlite 3
2020-11-29 00:32:36 +01:00

553 lines
22 KiB
HTML

<!DOCTYPE html>
<html><head>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<link href="sqlite.css" rel="stylesheet">
<title>Vulnerabilities</title>
<!-- path= -->
</head>
<body>
<div class=nosearch>
<a href="index.html">
<img class="logo" src="images/sqlite370_banner.gif" alt="SQLite" border="0">
</a>
<div><!-- IE hack to prevent disappearing logo --></div>
<div class="tagline desktoponly">
Small. Fast. Reliable.<br>Choose any three.
</div>
<div class="menu mainmenu">
<ul>
<li><a href="index.html">Home</a>
<li class='mobileonly'><a href="javascript:void(0)" onclick='toggle_div("submenu")'>Menu</a>
<li class='wideonly'><a href='about.html'>About</a>
<li class='desktoponly'><a href="docs.html">Documentation</a>
<li class='desktoponly'><a href="download.html">Download</a>
<li class='wideonly'><a href='copyright.html'>License</a>
<li class='desktoponly'><a href="support.html">Support</a>
<li class='desktoponly'><a href="prosupport.html">Purchase</a>
<li class='search' id='search_menubutton'>
<a href="javascript:void(0)" onclick='toggle_search()'>Search</a>
</ul>
</div>
<div class="menu submenu" id="submenu">
<ul>
<li><a href='about.html'>About</a>
<li><a href='docs.html'>Documentation</a>
<li><a href='download.html'>Download</a>
<li><a href='support.html'>Support</a>
<li><a href='prosupport.html'>Purchase</a>
</ul>
</div>
<div class="searchmenu" id="searchmenu">
<form method="GET" action="search">
<select name="s" id="searchtype">
<option value="d">Search Documentation</option>
<option value="c">Search Changelog</option>
</select>
<input type="text" name="q" id="searchbox" value="">
<input type="submit" value="Go">
</form>
</div>
</div>
<script>
function toggle_div(nm) {
var w = document.getElementById(nm);
if( w.style.display=="block" ){
w.style.display = "none";
}else{
w.style.display = "block";
}
}
function toggle_search() {
var w = document.getElementById("searchmenu");
if( w.style.display=="block" ){
w.style.display = "none";
} else {
w.style.display = "block";
setTimeout(function(){
document.getElementById("searchbox").focus()
}, 30);
}
}
function div_off(nm){document.getElementById(nm).style.display="none";}
window.onbeforeunload = function(e){div_off("submenu");}
/* Disable the Search feature if we are not operating from CGI, since */
/* Search is accomplished using CGI and will not work without it. */
if( !location.origin || !location.origin.match || !location.origin.match(/http/) ){
document.getElementById("search_menubutton").style.display = "none";
}
/* Used by the Hide/Show button beside syntax diagrams, to toggle the */
function hideorshow(btn,obj){
var x = document.getElementById(obj);
var b = document.getElementById(btn);
if( x.style.display!='none' ){
x.style.display = 'none';
b.innerHTML='show';
}else{
x.style.display = '';
b.innerHTML='hide';
}
return false;
}
</script>
</div>
<div class=fancy>
<div class=nosearch>
<div class="fancy_title">
Vulnerabilities
</div>
<div class="fancy_toc">
<a onclick="toggle_toc()">
<span class="fancy_toc_mark" id="toc_mk">&#x25ba;</span>
Table Of Contents
</a>
<div id="toc_sub"><div class="fancy-toc1"><a href="#executive_summary">1. Executive Summary</a></div>
<div class="fancy-toc1"><a href="#about_cves">2. About CVEs</a></div>
<div class="fancy-toc2"><a href="#a_separate_sql_injection_vulnerability_is_usually_required">2.1. A separate SQL injection vulnerability is usually required</a></div>
<div class="fancy-toc2"><a href="#defense_against_dark_arts">2.2. Defense Against Dark Arts</a></div>
<div class="fancy-toc2"><a href="#the_sqlite_developer_policy_toward_cves">2.3. The SQLite Developer Policy Toward CVEs</a></div>
<div class="fancy-toc1"><a href="#status_of_recent_sqlite_cves">3. Status Of Recent SQLite CVEs</a></div>
</div>
</div>
<script>
function toggle_toc(){
var sub = document.getElementById("toc_sub")
var mk = document.getElementById("toc_mk")
if( sub.style.display!="block" ){
sub.style.display = "block";
mk.innerHTML = "&#x25bc;";
} else {
sub.style.display = "none";
mk.innerHTML = "&#x25ba;";
}
}
</script>
</div>
<h1 id="executive_summary"><span>1. </span>Executive Summary</h1>
<ul>
<li><p>
CVEs about SQLite probably do not apply to your use of SQLite.
</p></li><li><p>
All historical vulnerabilities reported against SQLite require at least
one of these preconditions:
</p><ol type="1">
<li><p>
The attacker can submit and run arbitrary SQL statements.
</p></li><li><p>
The attacker can submit a maliciously crafted database file to the
application that the application will then open and query.
</p></li></ol>
</li><li><p>
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.
</p></li><li><p>
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.
</p></li><li><p>
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.
</p></li><li><p><a name="notnew"></a>
Very few CVEs written about SQLite are real vulnerabilities in the
sense that they do not give any new capabilities to an attacker.
Consider:
</p><ol type="a">
<li><p>
Almost all CVEs written against SQLite require the ability to
inject and run arbitrary SQL.
</p></li><li><p>
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.
</p></li><li><p>
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.
</p></li><li><p>
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.
</p></li></ol>
</li><li><p>
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.
</p></li><li><p>
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, but without success.
</p></li></ul>
<h1 id="about_cves"><span>2. </span>About CVEs</h1>
<p>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.
</p><p>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.
</p><p>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.
</p><h2 id="a_separate_sql_injection_vulnerability_is_usually_required"><span>2.1. </span>A separate SQL injection vulnerability is usually required</h2>
<p>
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.
</p><p>
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
<a href="https://en.wikipedia.org/wiki/SQL_injection">SQL Injection
vulnerability</a>. Since SQL text is executable code, an
SQL Injection vulnerability is actually a special case of a
<a href="https://en.wikipedia.org/wiki/Arbitrary_code_execution">Remote
Code Execution (RCE) vulnerability</a>. 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.
</p><p>
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.
</p><p>
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.
</p><p>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.
</p><h2 id="defense_against_dark_arts"><span>2.2. </span>Defense Against Dark Arts</h2>
<p>
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.
</p><p>
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 <a href="security.html">defense against dark arts</a> document
contains additional suggestions that can help prevent zero-day
attacks in cases where SQLite is given inputs that come directly
from untrusted sources.
</p><h2 id="the_sqlite_developer_policy_toward_cves"><span>2.3. </span>The SQLite Developer Policy Toward CVEs</h2>
<p>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
<a href="https://sqlite.org/src/timeline">public SQLite source tree</a>.
If a bug seems like it might cause problems for existing applications,
a new patch release for SQLite will be issued.
</p><p>However, the SQLite developers do not track CVEs. There are
various reasons for this:
</p><ol>
<li><p>
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.
</p></li><li><p>
CVEs are a low-quality source of information about bugs in SQLite
that are likely to affect most applications.
</p></li><li><p>
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.
</p></li><li><p>
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.
</p></li></ol>
<a name="cvetab"></a>
<h1 id="status_of_recent_sqlite_cves"><span>3. </span>Status Of Recent SQLite CVEs</h1>
<p>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.
</p><p>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 <a href="https://sqlite.org/forum/about">SQLite Forum</a> so they can
be added.
</p><table border="1" cellpadding="5" cellspacing="0" style="margin-left:5ex;">
<thead>
<tr>
<th valign="bottom">CVE Number</th>
<th valign="bottom">Fix</th>
<th valign="bottom">Comments</th>
</tr>
</thead>
<tbody>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-15358'>CVE-2020-15358</a>
</td>
<td valign='top'><a href="releaselog/3_32_3.html">3.32.3</a><br>(2020-06-18)</td>
<td valign='top'>Malicious SQL statement causes an read past the end of a heap buffer.
<a href='https://sqlite.org/src/info/8f157e8010b22af0'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13871'>CVE-2020-13871</a>
</td>
<td valign='top'><a href="releaselog/3_32_3.html">3.32.3</a><br>(2020-06-18)</td>
<td valign='top'>Malicious SQL statement causes a read-only use-after-free memory error.
<a href='https://sqlite.org/src/info/c8d3b9f0a750a529'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13632'>CVE-2020-13632</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement causes a read of a NULL pointer in the
<a href="fts3.html#matchinfo">matchinfo()</a> SQL function of the <a href="fts3.html">FTS3</a> extension, resulting in
denial of service.
<a href='https://sqlite.org/src/info/a4dd148928ea65bd'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13631'>CVE-2020-13631</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement (an ALTER TABLE that tries to rename a
<a href="vtab.html">virtual table</a> into one of its own <a href="vtab.html#xshadowname">shadow tables</a>)
causes an infinite loop and denial of service.
<a href='https://sqlite.org/src/info/eca0ba2cf4c0fdf7'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13630'>CVE-2020-13630</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement causes a read-only use-after-free,
possibly resulting in a incorrect output from the <a href="fts3.html#snippet">snippet()</a>
SQL function of the <a href="fts3.html">FTS3</a> extension. There is no known
way to exfiltrate data or crash the application using this bug.
<a href='https://sqlite.org/src/info/0d69f76f0865f962'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13435'>CVE-2020-13435</a>
</td>
<td valign='top'><a href="releaselog/3_32_1.html">3.32.1</a><br>(2020-05-25)</td>
<td valign='top'>Malicious SQL statement causes a read access to a NULL pointer and
denial of service.
<a href='https://www.sqlite.org/src/info/7a5279a25c57adf1'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13434'>CVE-2020-13434</a>
</td>
<td valign='top'><a href="releaselog/3_32_1.html">3.32.1</a><br>(2020-05-25)</td>
<td valign='top'>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.
<a href='https://www.sqlite.org/src/info/23439ea582241138'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-11656'>CVE-2020-11656</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement causes read-only use-after-free of memory allocation
if SQLite is compile with -DSQLITE_DEBUG. Does not affect release
builds.
<a href='https://www.sqlite.org/src/info/4722bdab08cb1'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-11655'>CVE-2020-11655</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement causes a read using an uninitialized pointer
and denial-of-service.
<a href='https://www.sqlite.org/src/info/af4556bb5c285c08'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-9327'>CVE-2020-9327</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement causes a read using an uninitialized pointer
and denial-of-service
<a href='https://www.sqlite.org/src/info/4374860b29383380'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-6405'>CVE-2020-6405</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes a NULL pointer dereference and
denial-of-service
<a href='https://www.sqlite.org/src/info/1bc783da63d58b05'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-20218'>CVE-2019-20218</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes an uninitialized pointer read and
denial-of-service.
<a href='https://www.sqlite.org/src/timeline?r=better-error-handling-1'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19959'>CVE-2019-19959</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes a NULL pointer dereference
in the <a href="zipfile.html">Zipfile virtual table</a> extension and
denial-of-service. This is only possible when the optional
<a href="zipfile.html">Zipfile virtual table</a> extension is deployed, which is not
the case in default builds.
<a href='https://www.sqlite.org/src/info/cc0fb00a128fd077'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19926'>CVE-2019-19926</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes an uninitialized pointer read and
denial-of-service.
<a href='https://www.sqlite.org/src/info/cba2a2a44cdf138a'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19925'>CVE-2019-19925</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes a NULL pointer dereference and
in the <a href="zipfile.html">Zipfile virtual table</a> extension and
denial-of-service. This is only possible when the optional
<a href="zipfile.html">Zipfile virtual table</a> extension is deployed, which is not
the case in default builds.
<a href='https://www.sqlite.org/src/info/a80f84b511231204'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19924'>CVE-2019-19924</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes a uninitialized pointer reference and
denial-of-service.
<a href='https://www.sqlite.org/src/info/e2bddcd4c55ba3cb'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19923'>CVE-2019-19923</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes a NULL pointer dereference and
denial-of-service.
<a href='https://www.sqlite.org/src/info/862974312edf00e9'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19317'>CVE-2019-19317</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>This CVE identifies a bug in a development check-in of
SQLite. The bug never appeared in any official SQLite release.
<a href='https://www.sqlite.org/src/info/6601da58032d18ae'>(details)</a></td>
</tr>
</tbody>
</table>