Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Improvements to the CVE page. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
1cb2a5b6bc0506749306103d399435a1 |
User & Date: | drh 2020-05-19 19:37:34.815 |
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
Changes to pages/cves.in.
︙ | ︙ | |||
28 29 30 31 32 33 34 | 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 | | | 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | 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"> |
︙ | ︙ | |||
57 58 59 60 61 62 63 | 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> | | | | | | | 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 | 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 |
︙ | ︙ | |||
124 125 126 127 128 129 130 | 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 | | | | | 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 | 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 |
︙ | ︙ | |||
172 173 174 175 176 177 178 | 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 | | | 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 | 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. |
︙ | ︙ | |||
216 217 218 219 220 221 222 | and they do not like to be controlled by groups in which they have no voice. </ol> <tcl> hd_fragment cvetab {recent CVEs} | | | > > > > | 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 | 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 |
︙ | ︙ | |||
252 253 254 255 256 257 258 | <th valign="bottom">Comments</th> </tr> </thead> <tbody> <tcl> CVE 2020-11656 3.32.0 { | | > | | > | | | > | | | | > | > > > > > | < > > > | | | | 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 | <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> |