SQLite Forum

Timeline
Login

7 forum posts by user rrware

2020-05-12
00:24 Reply: When will/were recent "sqlite3 new security issues CVEs" be addressed? (artifact: 300bfeccc2 user: rrware)

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.

2020-05-06
17:14 Reply: When will/were recent "sqlite3 new security issues CVEs" be addressed? (artifact: 4042ae21e1 user: rrware)

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.

2020-04-30
18:23 Reply: When will/were recent "sqlite3 new security issues CVEs" be addressed? (artifact: ee3740e0a7 user: rrware)

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.

16:57 Reply: When will/were recent "sqlite3 new security issues CVEs" be addressed? (artifact: ea7af70cbc user: rrware)

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.

16:48 Reply: When will/were recent "sqlite3 new security issues CVEs" be addressed? (artifact: 3fafeb2391 user: rrware)

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.

2020-04-29
20:21 Reply: When will/were recent "sqlite3 new security issues CVEs" be addressed? (artifact: a84129aa4d user: rrware)

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.

2020-04-28
18:37 Reply: When will/were recent "sqlite3 new security issues CVEs" be addressed? (artifact: b91bf565fa user: rrware)

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.