Documentation Source Text

usually within hours of discovery.  New releases of SQLite
are issued if the bug seems likely to impact real-world
applications.

<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 in some cases no impact at all, but which make
exaggerated impact claims.

<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:
<ol type="a">
................................................................................
    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.
</ol>

<li><p>
The SQLite developers do not write CVEs.  Any CVEs you find written against
SQLite are generated by third-parties, often without any input from the
core developers.  Or, sometimes 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.  The SQLite developers have attempted
to add clarifications and fix inaccuracies in existing CVEs about SQLite, 
but so far without success.  You should not assume that a CVE about
SQLite contains true and accurate information.


<li><p>
Do not panic about CVEs that you might see written against SQLite.
They probably do not apply to you or to your use of SQLite.
</ul>

<h1>About CVEs</h1>

<p>CVEs ("Common Vulnerabilities and Exposures") are reports of software
bugs that might allow a system to be hacked.  The idea
................................................................................
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 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 say Python or shell script or raw machine code.
Nevertheless, an SQL Injection is a serious problem.

<p>
Most CVEs written against 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>
A few applications do allow untrusted SQL scripts received from
potentially hostile agents to be run direct in SQLite.  The main
................................................................................
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>
However, there are some occasions where an application does need
to be able to safely run untrusted SQL.   The 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. 

................................................................................
and they do not like to be controlled by groups in which they have
no voice.
</ol>


<tcl>
hd_fragment cvetab {recent CVEs}
proc CVE {num fix com} {
  hd_puts "<tr><td valign='top'>\n"
  hd_puts "<a href='https://nvd.nist.gov/vuln/detail/CVE-$num'>CVE-$num</a>\n"
  hd_puts "</td>\n"
  hd_puts "<td valign='top'>"
  hd_resolve "\[version $fix|$fix\]<br>(\[dateof:$fix\])</td>\n"
  hd_resolve "<td valign='top'>[string trim $com]</td>\n"




  hd_puts "</tr>\n\n"
}
</tcl>
<h1>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
................................................................................
<th valign="bottom">Comments</th>
</tr>
</thead>
<tbody>

<tcl>
CVE 2020-11656 3.32.0 {
  Malicious SQL statement causes use-after-free of memory allocation
  if SQLite is compile with -DSQLITE_DEBUG.  Does not affect release
  builds.

}
CVE 2020-11655 3.32.0 {
  Malicious SQL statement causes an uninitialized pointer reference
  and denial-of-service.

}
CVE 2020-9327 3.32.0 {
  Malicious SQL statement causes an uninitialized pointer reference and
  denial-of-service

}
CVE 2020-6405 3.31.0 {
  Malicious SQL statement causes a NULL pointer dereference and
  denial-of-service
}

CVE 2019-20218 3.31.0 {
  Malicious SQL statement causes an uninitialized pointer dereference and
  denial-of-service.
}

CVE 2019-19959 3.31.0 {
  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.

}





CVE 2019-19925 3.31.0 {
  Malicious SQL statement causes a NULL pointer dereference and

  denial-of-service.
}




CVE 2019-19924 3.31.0 {
  Malicious SQL statement causes a uninitialized pointer reference and
  denial-of-service.
}

CVE 2019-19923 3.31.0 {
  Malicious SQL statement causes a NULL pointer dereference and
  denial-of-service.
}

CVE 2019-19317 3.31.0 {
  This CVE identifies a bug in a development check-in of
  SQLite.  The bug never appeared in any official SQLite release.
}

</tcl>
</tbody>
</table>

usually within hours of discovery.  New releases of SQLite
are issued if the bug seems likely to impact real-world
applications.

<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.

<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:
<ol type="a">
................................................................................
    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.
</ol>

<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.  The SQLite developers have attempted
to add clarifications and fix inaccuracies in existing CVEs about SQLite,
but so far without success.  You should not assume that a CVE about
SQLite contains true and accurate information.


<li><p>
Do not panic about CVEs that reference SQLite.
They probably do not apply to you or to your use of SQLite.
</ul>

<h1>About CVEs</h1>

<p>CVEs ("Common Vulnerabilities and Exposures") are reports of software
bugs that might allow a system to be hacked.  The idea
................................................................................
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>
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>
A few applications do allow untrusted SQL scripts received from
potentially hostile agents to be run direct in SQLite.  The main
................................................................................
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>
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. 

................................................................................
and they do not like to be controlled by groups in which they have
no voice.
</ol>


<tcl>
hd_fragment cvetab {recent CVEs}
proc CVE {num fix com {url {}}} {
  hd_puts "<tr><td valign='top'>\n"
  hd_puts "<a href='https://nvd.nist.gov/vuln/detail/CVE-$num'>CVE-$num</a>\n"
  hd_puts "</td>\n"
  hd_puts "<td valign='top'>"
  hd_resolve "\[version $fix|$fix\]<br>(\[dateof:$fix\])</td>\n"
  hd_resolve "<td valign='top'>[string trim $com]"
  if {$url!=""} {
    hd_puts "\n<a href='$url'>(details)</a>"
  }
  hd_puts "</td>\n"
  hd_puts "</tr>\n\n"
}
</tcl>
<h1>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
................................................................................
<th valign="bottom">Comments</th>
</tr>
</thead>
<tbody>

<tcl>
CVE 2020-11656 3.32.0 {
  Malicious SQL statement causes read-only use-after-free of memory allocation
  if SQLite is compile with -DSQLITE_DEBUG.  Does not affect release
  builds.
} {https://www.sqlite.org/src/info/4722bdab08cb1}

CVE 2020-11655 3.32.0 {
  Malicious SQL statement causes a read using an uninitialized pointer
  and denial-of-service.
} {https://www.sqlite.org/src/info/af4556bb5c285c08}

CVE 2020-9327 3.32.0 {
  Malicious SQL statement causes a read using an uninitialized pointer
  and denial-of-service
} {https://www.sqlite.org/src/info/4374860b29383380}

CVE 2020-6405 3.31.0 {
  Malicious SQL statement causes a NULL pointer dereference and
  denial-of-service
} {https://www.sqlite.org/src/info/1bc783da63d58b05}

CVE 2019-20218 3.31.0 {
  Malicious SQL statement causes an uninitialized pointer read and
  denial-of-service.
} {https://www.sqlite.org/src/timeline?r=better-error-handling-1}

CVE 2019-19959 3.31.0 {
  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.
} {https://www.sqlite.org/src/info/cc0fb00a128fd077}

CVE 2019-19926 3.31.0 {
  Malicious SQL statement causes an uninitialized pointer read and
  denial-of-service.
} {https://www.sqlite.org/src/info/cba2a2a44cdf138a}

CVE 2019-19925 3.31.0 {
  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.
} {https://www.sqlite.org/src/info/a80f84b511231204}

CVE 2019-19924 3.31.0 {
  Malicious SQL statement causes a uninitialized pointer reference and
  denial-of-service.
} {https://www.sqlite.org/src/info/e2bddcd4c55ba3cb}

CVE 2019-19923 3.31.0 {
  Malicious SQL statement causes a NULL pointer dereference and
  denial-of-service.
} {https://www.sqlite.org/src/info/862974312edf00e9}

CVE 2019-19317 3.31.0 {
  This CVE identifies a bug in a development check-in of
  SQLite.  The bug never appeared in any official SQLite release.
} {https://www.sqlite.org/src/info/6601da58032d18ae}

</tcl>
</tbody>
</table>