Documentation Source Text

Check-in [1cb2a5b6bc]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Improvements to the CVE page.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 1cb2a5b6bc0506749306103d399435a120df032d2783633d633fc4d3d6e22a16
User & Date: drh 2020-05-19 19:37:34
Original Comment: Improvesments to the CVE page.
Context
2020-05-20
01:24
Fix the INSERT syntax diagram so that it is not possible to go from DEFAULT VALUES to the upsert-clause. check-in: e42edf1dd3 user: drh tags: trunk
2020-05-19
19:37
Improvements to the CVE page. check-in: 1cb2a5b6bc user: drh tags: trunk
12:37
Update the speed and size charts. check-in: 386621474b user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/cves.in.

28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
..
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
...
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
...
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
...
216
217
218
219
220
221
222
223
224
225
226
227
228
229




230
231
232
233
234
235
236
...
252
253
254
255
256
257
258
259
260
261

262
263
264
265

266
267
268
269

270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286

287




288
289
290

291
292



293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
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>







|







 







|

|
|

|





|







 







|


|



|







 







|







 







|





|
>
>
>
>







 







|


>
|

|

>
|

|
|
>
|



|


|

|







>
|
>
>
>
>



>
|
<
>
>
>




|




|




|




28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
..
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
...
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
...
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
...
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
...
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304

305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
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>