[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Request for help/comments: sqlite3



(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

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: