All known security issues are fixed in SQLite 3.31.1.

We do not track CVEs. The information content of CVEs is very low, to the point of being non-useful. CVEs were originally a great idea. But they have evolved into a kind of badge-of-honor for armies of gray-hat hackers. The companies that employ these hackers evaluate employee performance in part on the number of CVEs they have generated. When people's performance evaluation depends on how many CVEs they write, you can probably guess what happens to the quantity and quality of the resulting CVEs.

Pretty much every CVE that has ever been written against SQLite assumes that the attacker has the ability to inject arbitrary SQL into SQLite. In other words, there has to be an SQL-injection bug in the application in order for any of these CVEs to come into play. There are some applications that do legitimately allow untrusted remote agents to inject arbitrary SQL, and SQLite should be (and is - with the latest patches) proof against exploits from arbitrary SQL injection. (See the "Defense Against Dark Arts" page for further information.) The vast majority of applications, however, do not allow a remote attacker to inject arbitrary SQL, and so even in older unpatched versions of SQLite, the vast majority of applications are not vulnerable.

CVS-2019-19317 is an excellent example of a bogus CVE. This CVE describes a bug in an unreleased development version of SQLite. We were working on the new generated columns feature of SQLite, and a third-party hacker found an error in the code under active development, and then wrote a CVE against it. The error was fixed before the problem was ever released, and yet still there is this CVE sitting out there, unresolved, and as far as I can tell unresolveable.

I agree that CVE-2019-19317 is bogus. You might want to dispute it, although I am not familiar with the process for doing so.

There are 156 CVEs which mention SQLite. Some of them are genuine and have been fixed. But many of them are really in the way software calls the SQLite API (e.g. unsanitized SQL), or in 'trunk' versions of SQLite which were never assigned a proper version number, or are things that the SQLite documentation prominently tells you about (e.g. until you say otherwise, FOREIGN KEYs are ignored).

You can't dispute those CVEs. Because the statement in the CVE report is true. It's just something that won't affect a competent programmer. DRH should not need to waste hours reading every vulnerability site out there and writing a closely argued refutation every time someone gets 'points' by posting there.

Report bugs, including vulnerabilities to the SQLite fora. They will get fixed or you will get an explanation (even from someone as far from the dev team as me) as to why they're not a problem.

Thanks, @drh for the info.

I appreciate your perspective @drh. However, if no one from the SQLite community participates in the process, you will continue to have these issues. You are absolutely correct that CVE-2019-19317 is bogus. If someone from the SQLite community participated in the process, they can dispute reports like that or be proactively notified about new ones.

I also appreciate concerns that you've brought up here and elsewhere about the current computer security environment. I think we all have concerns around the current CVE driven security environment where researchers are trying to make a name for themselves. It's unfortunate. However, it actually is the environment that is out there. The "badge-of-honor for armies of gray-hat hackers" isn't going to go away anytime soon and for better or worse they are actually right some of the time.

If the SQLite community doesn't participate in the process, there will always be questions about the security of SQLite in ways where it's not needed. For example, CVE-2019-19317 is still there with incorrect information.

I attempted to engage with NIST about this. Maybe I did it wrong, or contacted the wrong people, but for whatever reason, they seemed to have no interest in my input regarding CVEs written against SQLite.

Maybe you know better how to interact with NIST? Care to offer advice on how to go about making a difference - about how to go about updating and correcting CVEs written against SQLite?

As far as I've seen so far, the NIST organization in charge of CVEs is opaque and unaccountable. They do not, in my experience, seem interested in improving the quality of CVEs. To my mind, this is all the more reason to not pay any attention to CVEs.

I suppose that whenever NIST publishes false information about SQLite, I could sue them for libel. That would likely get their attention and might provoke a more helpful response whenever I write to them about problems in their reports. But starting lawsuits is expensive and contentious, does not actually improve the software in any way, and takes time away from actually working to make SQLite better. So, I figure it is better to just ignore NIST and hope that they will soon go away.

Maybe it's just me (maybe its just wishful thinking on my part) but I get the sense that people are more and more aware of the deficiencies of CVEs (as currently implemented) and are correspondingly less concerned with them.

Thanks for the response. I know you're busy doing things like actually making SQLite 3 better.

I can understand why you feel this way about NIST. Unfortunately what has happened to them is a system they created in 1999 to handle a few thousand CVEs has been put in a position where it had to process ~16k CVEs last year and the resources (in my opinion) just aren't there to do it right. At the same time, the process is opaque and not user friendly.

I'm more than happy to write up a guide to help. I would also be willing to take a more active roll in helping the community respond to new and/or unwarranted CVEs if that would be helpful. Just let me know what works best for you.

I'm more than happy to write up a guide to help.

Bullet-points for me that explain what consumers of CVEs expect would be helpful.

Would it be helpful for there to be a page on https://sqlite.org/ that described the current status of all known CVEs from the perspective of the SQLite developers?

Examples:

• CVE-2020-11656 → Use-after-free error on debugging builds only. No impact on release builds. Fix will be part of 3.32.0.

• CVE-2019-16168 → If the containing application includes an SQL Injection vulnerability then an attacker might be able to exploit that vulnerability to induce a division-by-zero in SQLite. Fixed in 3.29.0.

• CVE-2019-19317 → A bug in a development branch of SQLite. Never appeared in any official SQLite release.

And so forth...

This would be fantastically useful in my work. We have a third party system that automatically monitors CVEs, and when one appears for SQLite I need to respond/explain as its internal maintainer.

Usually I can figure it out from posts on the mailing list/forum and/or release notes, but an explicit list like you propose would greatly simplify that effort.

(I will acknowledge that overall this is not a significant waste of time since the number of CVEs coming through are quite low.)

Donald Shepherd

CVE-2020-11656 → Use-after-free error on debugging builds only. No impact on release builds. Fix will be part of 3.32.0.

Is this another case where you've gotten a CVE for something that was never in a release? If so, this is definitively not acceptable behavior on the part of the security researcher. Sure, it's nice to know but you don't file a CVE on something that isn't released.

I do think having a table for what the community's response for any particular CVE is would be a great way for the community to socialize what issues it feels are bogus as well as letting people who are consumers of SQLite what the community feels the right action is.

I'm more than happy to write up a guide to help.

I'll be putting something together for this.

CVE-2020-11656 → Use-after-free error on debugging builds only. No impact on release builds. Fix will be part of 3.32.0.

I assume this isn't another case of cherry picking from master but is just debug builds. Annoying.

I do think having a table for what the community's response for any particular CVE is would be a great way for the community to socialize what issues it feels are bogus as well as letting people who are consumers of SQLite what the community feels the right action is.

I'm more than happy to write up a guide to help.

I'll be putting something together for this.

CVE-2020-11656 is a bug in an official release. However, the bug was in test logic that is only included in the binary if you compile with -DSQLITE_DEBUG. For deployment builds in which -DSQLITE_DEBUG is omitted then it was impossible to encounter the problem, as far as we can determine.

How do I express this constraint so that it is apparent to a typical CVE reader?

Sorry about the duplicate post. Apparently you can't delete a post before it has been moderated. I didn't realizing clicking the "Delete" button actually made a new reply and neither actually deletes or lets you edit the previous post. Alas...

How do I express this constraint so that it is apparent to a typical CVE reader?

This should be very simple. I would simply state that:

• This vulnerability is only present if compiled with debug capabilities (i.e. -DSQLITE_DEBUG enabled).
• Binaries provided by sqlite.org are not vulnerable because they are not compiled with -DSQLITE_DEBUG.

That last bullet is an assumption on my part. If there are non-obvious exceptions to that which I can't see on the Downloads page, you should call them out. That statement should make the scope clear. It won't get the CVE changed but will let consumers of SQLite know the community position. I'll have some info for you later on how we do that.

I've had positive experiences getting CVEs corrected, usually within a day or so of emailing NVD. I always try to keep in mind that the NVD analyst team is very busy and has to deal with a diverse range of vulnerabilities that they can't become experts in every product/component, and the occasional error happens. So my advice would be:

• Be gracious
• Stick to the facts
• Describe what's wrong in the data, and propose a correction (follow and understand precedent from other entries in the NVD)
• Provide links to supporting material when appropriate

There is also a facility for vendors to make official statements; this doesn't change the CVE but will help users analyze within the context of their environment/application. More information about this process is at https://nvd.nist.gov/vuln/vendor-comments. An example where the CVE was disputed as actually in a pre-release version is https://nvd.nist.gov/vuln/detail/CVE-2007-4239.

To Ryan's suggestion, I would consider it an error that the description of CVE-2020-11656 does not mention SQLITE_DEBUG -- it's an important constraint on the set of vulnerable systems. Stating that binaries provided by sqlite.org are not compiled with SQLITE_DEBUG would be better suited for a vendor statement, since SQLite is often compiled from source and any product in the universe might have SQLITE_DEBUG turned on. (A similar line of reasoning applies here as, for example, a hypothetical vulnerability in the rtree extension. Developers of products that use SQLite need to evaluate and decide whether an update/release is in order. If a product doesn't use rtree than that product isn't affected.)

Hey @drh,

A couple of things. First, for the CVEs that the community questions, take a look at the links here. For the CVEs that need correction, follow the link for the CVE Request web form and select "Request an update to an existing CVE Entry" and fill out the relevant information. If you have a PGP key, great. If not, don't worry about it.

If you do not get an adequate response, please let me know.

The other thing to consider is going down the path of having the SQLite community become its own CVE Numbering Authority (CNA). This would give you and the community much more control over what CVEs get published for SQLite. For example, you would have first right of refusal. You would also have the ability to directly control the contents of CVEs. It doesn't come with zero effort, but it is something you might want to consider. If this sounds attractive, let me know and we can discuss how it can happen.

Finally, Peter is completely right about the statement about the SQLITE_DEBUG option above. I didn't mean to imply that statement should go into the CVE itself. That's not the appropriate place. But it would be good for there to be a statement as such somewhere relevant on the SQLite site so that users of the binaries from the SQLite site who see the CVE might have an answer to the question of if they are affected.

I've been working on a draft web-page about CVEs and SQLite. It includes a table of recent CVEs.

But it occurs to me that I am perhaps giving this CVEs more weight than they deserve. All of these CVEs can be safely ignored. Follow my logic:

1. All of the CVEs have a precondition that the attacker must be able to inject and run arbitrary SQL.

2. The worst outcome is denial-of-service.

3. But if an attacker has the ability to inject and run arbitrary SQL, they don't need any bugs in SQLite in order to execute a denial of service attack. All they have to do is puts in some SQL that uses a lot of CPU or memory or disk I/O and they can effectively shut the service down that way. It isn't hard to devise a small bit of perfectly valid and legal SQL that uses an enormous amount of CPU or memory.

4. Hence, none of the CVEs in the chart are "real". They are bugs (now fixed), but none of them give an attacker any more leverage for disrupting the system than the attacker had to begin with.

Am I completely off-base with this argument?

Small typo in the first paragraph:

Thought the SQLite developers do not consider CVEs...

First word should be "though".

Much more serious problem: no Defense Against the Dark Arts teacher lasted more than a year past their appointment.

drh, please reconsider taking on this role. We still need you. :)

The worst outcome is denial-of-service.

Not necessarily.

A use-after-free bug could be exploited if the attacker can influence the program to allocate memory with interesting data at the same address as the just-freed data. An uninitialized-pointer bug could be exploited if the attacker can influence the value of the pointer, or if he can predict the value of the pointer and influence the program to place interesting data at that address.

This is strongly dependent on architecture, configuration, and other circumstances, usually requires other bugs, and takes much more effort than running SQLite through a fuzzer. But it cannot be ruled out completely.

Am I completely off-base with this argument?

I actually lean towards what @cladisch thoughts are here.

That said, the information above should be sent to MITRE for each CVE where the CVE doesn't reflect this information. For example, CVE-2020-11655 should clearly call out it's only for debug builds. For CVE-2019-19959, if you look at the CVSSv3.1 vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) it immediately brings a number of questions to mind. Given SQLite's documented usage guidance, is it really an Attack Vector of Network or should it be Adjacent Network. Is the Attack Complexity really Low? I don't believe Privileges Required is None given #3 above. Is Integrity Impact really High or is it Low?

For that particular CVE, if those items were actually other values, the CVSS score goes from a 7.5 to a 2.6. I'm not saying that's the right change since I'm not the SQLite expert, but at least some of the underlying CVSSv3 metrics chosen seem...questionable. I'm guessing it's the same for many or most of your other CVEs.

If you haven't looked, you should take a look at the MITRE CVSSv3 calculator. If you have a question on what a specific metric means, there is lots of explanation in the hover text.

In the CVEs referenced in the report, the only use-after-free occurs inside of SQLITE_DEBUG code. It is a read only, not a write. It's whole purpose is to trigger an alert on valgrind or ASAN to show us where we neglected to clean up a data structure in the ALTER TABLE operation. It only occurs on debug builds, and is harmless even then.

The only uninitialized pointer dereferences are all read operations as well, so there is no mechanisms available to subvert data elsewhere in the system.