Re: Request for help/comments: sqlite3

Hi Jonas

I have now looked into this problem to see if I can out something.

What I have done is to backtrack whether the code is ever executed by sqlite and I cannot find that it can be.

rtreenode function is registered using sqlite3_create_function in sqlite3_rtree_init. But I cannot find that the sqlite4_rtree_init function to be called from anywhere.

Based on this I think we can rather safely say that the function is not used in Debian and hence the package is not affected. I think we usually mark it as ignored with a description. An alternative is to mark it as not-affected but I'm not sure whether that should be done in this case since the vulnerability is there, just not triggered. Someone else can maybe help out with that decision.

In addition to that I think we can rather safely mark it as ignored (at least postponed) since should be seen as a minor issue. Such debug functions should not be used in live applications and hence the problem is not that big. SQL permissions in sqlite is not really something you give access to any user, at least that is my interpretation of its general use.

I hope this helps a little.

Best regards

// Ola

On Thu, 13 Jun 2019 at 15:46, Jonas Meurer <jonas@freesources.org> wrote:

(Putting Security Team in the loop as they're very likely to run into
the same problem.)

Hello,

I spent quite some hours trying to backport the fix for CVE-2019-8457[1]
to sqlite3 in Jessie. That ended in backporting huge amounts of upstream
changes and in the end I decided to not further go this path. So I'm
asking for some ideas on how to move on.

Given that according to the docs the whole function in question
(rtreenode()) is meant to be "used for debugging and analysis", I'm not
sure it's worth spending any more time on doing the backport.

According to codesearch.debian.net[2], rtreenode() is not used at all in
Debian, the only occurences are code duplications where sqlite3 sources
are shipped within other source packages.

I tend to skip this fix for Jessie (and recommend the same to the
Security Team for Stretch). What do you think about it?

---

In the following, I'll explain more details of my findings:

The problem is that the whole point of the upstream fix[3] is to migrate
the rtreenode() function in ext/rtree.c to use the new sqlite3_str
object, which brings better and less error-prone error reporting.

sqlite3_str is an object used to pile up text (e.g. error messages)
without knowing the end size of the text string. It basically replaces
the old StrAccum object. Logically, the upstream commit[4] that
introduced sqlite3_str comes with a huge amount of restructuring,
replacing all old functions around StrAccum with new ones that use
sqlite3_str instead.

Backporting the whole StrAccum -> sqlite3_str migration doesn't seem
sensible to me. It would mean very intrusive code changes that I don't
feel comfortable doing in a security update targeted at (old-)stable.

I first had hope to be able to partially backport the new sqlite3_str
object and associated functions (without replacing the old StrAccum
stuff) and use them in rtreenode(), but it turned out that doesn't work.
I decided to stop this attempt when finally having to backport
sqlite3_str_vappendf()[5], which would bring huge amounts of code
duplication.

I'm looking forward to hear your thoughts and commments :)

Cheers
jonas

[1] https://security-tracker.debian.org/tracker/CVE-2019-8457
[2] https://codesearch.debian.net/search?q=rtreenode%5C%28&perpkg=1
[3] https://www.sqlite.org/src/info/90acdbfce9c08858 or
https://github.com/sqlite/sqlite/commit/e41fd72
[4] https://github.com/sqlite/sqlite/commit/0cdbe1a
[5] https://github.com/sqlite/sqlite/blob/master/src/printf.c#L197-L888