Summary: | Multiple sqlite3 vulnerabilities (ports and base) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | rob2g2 <rob2g2-freebsd> | ||||||
Component: | Individual Port(s) | Assignee: | Security Team <secteam> | ||||||
Status: | Closed FIXED | ||||||||
Severity: | Affects Many People | CC: | cy, dvl, einar, emaste, pauamma, pavelivolkov, philip, pi, ports-secteam, ports-security, rob2g2-freebsd, secteam, vvd, zeising | ||||||
Priority: | Normal | Keywords: | needs-qa, security | ||||||
Version: | Latest | Flags: | koobs:
maintainer-feedback+
koobs: maintainer-feedback? (secteam) koobs: merge-quarterly+ |
||||||
Hardware: | Any | ||||||||
OS: | Any | ||||||||
URL: | https://www.sqlite.org/changes.html | ||||||||
Attachments: |
|
Thank you for the report. Presumably this affects sqlite in base as well? Yes. The updated port is compiling here. Working on the vendor branch import. Vendor import is done. Port builds cleanly. Should I commit the port now or when base is committed? universe13b will do the heavy lifting. The URL in the patch is about GIT. The port is commmitted to my git repo. I prefer to have an approved by before I push it to svn. A commit references this bug: Author: cy Date: Fri Jun 12 13:02:46 UTC 2020 New revision: 362095 URL: https://svnweb.freebsd.org/changeset/base/362095 Log: MFV r362082: Update sqlite3 3.31.1 --> 3.32.0. PR: 247149 Reported by: spam123@bitbert.com Reminded by: emaste MFC after: 3 days Security: CVE-2020-11655, CVE-2020-13434, CVE-2020-13435, CVE-2020-13630, CVE-2020-13631, CVE-2020-13632 Changes: _U head/contrib/sqlite3/ head/contrib/sqlite3/Makefile.msc head/contrib/sqlite3/configure head/contrib/sqlite3/configure.ac head/contrib/sqlite3/shell.c head/contrib/sqlite3/sqlite3.c head/contrib/sqlite3/sqlite3.h head/contrib/sqlite3/sqlite3ext.h head/contrib/sqlite3/tea/configure head/contrib/sqlite3/tea/configure.ac head/contrib/sqlite3/tea/generic/tclsqlite3.c A commit references this bug: Author: cy Date: Fri Jun 12 13:02:53 UTC 2020 New revision: 538614 URL: https://svnweb.freebsd.org/changeset/ports/538614 Log: Update 3.31.1 --> 3.32.0 Address multiple security vulnerabilities. PR: 247149 Reported by: spam123@bitbert.com Reminded by: emaste Approved by: Approved by: portmgr (blanket: security bugfix) MFH: 2020Q2 Security: CVE-2020-11655, CVE-2020-13434, CVE-2020-13435, CVE-2020-13630, CVE-2020-13631, CVE-2020-13632 Changes: head/databases/sqlite3/Makefile head/databases/sqlite3/distinfo head/databases/sqlite3/files/patch-sqlite3.c The vuxml patch needs a bit of cleanup too. A commit references this bug: Author: cy Date: Sat Jun 13 04:43:35 UTC 2020 New revision: 538637 URL: https://svnweb.freebsd.org/changeset/ports/538637 Log: Document multiple sqlite3 vulnerabilities with CVSS scores ranging from 5.5 (medium) to 7.5 (high). PR: 247149 Changes: head/security/vuxml/vuln.xml sqlite3 3.32.0 will not fix all of the CVEs. 3.32.2 will be committed. A commit references this bug: Author: cy Date: Sat Jun 13 04:48:16 UTC 2020 New revision: 362145 URL: https://svnweb.freebsd.org/changeset/base/362145 Log: MFV r362143: Update sqlite3 to 3.32.2 (3320200). CVE-2020-11655: SQLite through 3.31.1 allows attackers to cause a denial of service (segmentation fault) via a malformed window-function query because the AggInfo object's initialization is mishandled. CVE-2020-13434: SQLite through 3.32.0 has an integer overflow in sqlite3_str_vappendf in printf.c. CVE-2020-13435: SQLite through 3.32.0 has a segmentation fault in sqlite3ExprCodeTarget in expr.c. CVE-2020-13630: ext/fts3/fts3.c in SQLite before 3.32.0 has a use-after-free in fts3EvalNextRow, related to the snippet feature CVE-2020-13631: SQLite before 3.32.0 allows a virtual table to be renamed to the name of one of its shadow tables, related to alter.c and build.c. CVE-2020-13632: ext/fts3/fts3_snippet.c in SQLite before 3.32.0 ha s a NULL pointer dereference via a crafted matchinfo() query. PR: 247149 Reported by: spam123@bitbert.com MFC after: 3 days Security: vuxml: c4ac9c79-ab37-11ea-8b5e-b42e99a1b9c3 https://nvd.nist.gov/vuln/detail/CVE-2020-11655 https://nvd.nist.gov/vuln/detail/CVE-2020-13434 https://nvd.nist.gov/vuln/detail/CVE-2020-13435 https://nvd.nist.gov/vuln/detail/CVE-2020-13630 https://nvd.nist.gov/vuln/detail/CVE-2020-13631 https://nvd.nist.gov/vuln/detail/CVE-2020-13632 Changes: _U head/contrib/sqlite3/ head/contrib/sqlite3/configure head/contrib/sqlite3/configure.ac head/contrib/sqlite3/shell.c head/contrib/sqlite3/sqlite3.c head/contrib/sqlite3/sqlite3.h head/contrib/sqlite3/tea/configure head/contrib/sqlite3/tea/configure.ac A commit references this bug: Author: cy Date: Mon Jun 15 03:10:57 UTC 2020 New revision: 362190 URL: https://svnweb.freebsd.org/changeset/base/362190 Log: MFC r362095, r362145 r362095: MFV r362082: Update sqlite3 3.31.1 --> 3.32.0. PR: 247149 Reported by: spam123@bitbert.com Reminded by: emaste Security: CVE-2020-11655, CVE-2020-13434, CVE-2020-13435, CVE-2020-13630, CVE-2020-13631, CVE-2020-13632 r362145: MFV r362143: Update sqlite3 to 3.32.2 (3320200). CVE-2020-11655: SQLite through 3.31.1 allows attackers to cause a denial of service (segmentation fault) via a malformed window-function query because the AggInfo object's initialization is mishandled. CVE-2020-13434: SQLite through 3.32.0 has an integer overflow in sqlite3_str_vappendf in printf.c. CVE-2020-13435: SQLite through 3.32.0 has a segmentation fault in sqlite3ExprCodeTarget in expr.c. CVE-2020-13630: ext/fts3/fts3.c in SQLite before 3.32.0 has a use-after-free in fts3EvalNextRow, related to the snippet feature CVE-2020-13631: SQLite before 3.32.0 allows a virtual table to be renamed to the name of one of its shadow tables, related to alter.c and build.c. CVE-2020-13632: ext/fts3/fts3_snippet.c in SQLite before 3.32.0 ha s a NULL pointer dereference via a crafted matchinfo() query. PR: 247149 Reported by: spam123@bitbert.com Security: vuxml: c4ac9c79-ab37-11ea-8b5e-b42e99a1b9c3 https://nvd.nist.gov/vuln/detail/CVE-2020-11655 https://nvd.nist.gov/vuln/detail/CVE-2020-13434 https://nvd.nist.gov/vuln/detail/CVE-2020-13435 https://nvd.nist.gov/vuln/detail/CVE-2020-13630 https://nvd.nist.gov/vuln/detail/CVE-2020-13631 https://nvd.nist.gov/vuln/detail/CVE-2020-13632 Changes: _U stable/11/ stable/11/contrib/sqlite3/Makefile.msc stable/11/contrib/sqlite3/configure stable/11/contrib/sqlite3/configure.ac stable/11/contrib/sqlite3/shell.c stable/11/contrib/sqlite3/sqlite3.c stable/11/contrib/sqlite3/sqlite3.h stable/11/contrib/sqlite3/sqlite3ext.h stable/11/contrib/sqlite3/tea/configure stable/11/contrib/sqlite3/tea/configure.ac stable/11/contrib/sqlite3/tea/generic/tclsqlite3.c _U stable/12/ stable/12/contrib/sqlite3/Makefile.msc stable/12/contrib/sqlite3/configure stable/12/contrib/sqlite3/configure.ac stable/12/contrib/sqlite3/shell.c stable/12/contrib/sqlite3/sqlite3.c stable/12/contrib/sqlite3/sqlite3.h stable/12/contrib/sqlite3/sqlite3ext.h stable/12/contrib/sqlite3/tea/configure stable/12/contrib/sqlite3/tea/configure.ac stable/12/contrib/sqlite3/tea/generic/tclsqlite3.c A commit references this bug: Author: cy Date: Mon Jun 15 03:10:57 UTC 2020 New revision: 362190 URL: https://svnweb.freebsd.org/changeset/base/362190 Log: MFC r362095, r362145 r362095: MFV r362082: Update sqlite3 3.31.1 --> 3.32.0. PR: 247149 Reported by: spam123@bitbert.com Reminded by: emaste Security: CVE-2020-11655, CVE-2020-13434, CVE-2020-13435, CVE-2020-13630, CVE-2020-13631, CVE-2020-13632 r362145: MFV r362143: Update sqlite3 to 3.32.2 (3320200). CVE-2020-11655: SQLite through 3.31.1 allows attackers to cause a denial of service (segmentation fault) via a malformed window-function query because the AggInfo object's initialization is mishandled. CVE-2020-13434: SQLite through 3.32.0 has an integer overflow in sqlite3_str_vappendf in printf.c. CVE-2020-13435: SQLite through 3.32.0 has a segmentation fault in sqlite3ExprCodeTarget in expr.c. CVE-2020-13630: ext/fts3/fts3.c in SQLite before 3.32.0 has a use-after-free in fts3EvalNextRow, related to the snippet feature CVE-2020-13631: SQLite before 3.32.0 allows a virtual table to be renamed to the name of one of its shadow tables, related to alter.c and build.c. CVE-2020-13632: ext/fts3/fts3_snippet.c in SQLite before 3.32.0 ha s a NULL pointer dereference via a crafted matchinfo() query. PR: 247149 Reported by: spam123@bitbert.com Security: vuxml: c4ac9c79-ab37-11ea-8b5e-b42e99a1b9c3 https://nvd.nist.gov/vuln/detail/CVE-2020-11655 https://nvd.nist.gov/vuln/detail/CVE-2020-13434 https://nvd.nist.gov/vuln/detail/CVE-2020-13435 https://nvd.nist.gov/vuln/detail/CVE-2020-13630 https://nvd.nist.gov/vuln/detail/CVE-2020-13631 https://nvd.nist.gov/vuln/detail/CVE-2020-13632 Changes: _U stable/11/ stable/11/contrib/sqlite3/Makefile.msc stable/11/contrib/sqlite3/configure stable/11/contrib/sqlite3/configure.ac stable/11/contrib/sqlite3/shell.c stable/11/contrib/sqlite3/sqlite3.c stable/11/contrib/sqlite3/sqlite3.h stable/11/contrib/sqlite3/sqlite3ext.h stable/11/contrib/sqlite3/tea/configure stable/11/contrib/sqlite3/tea/configure.ac stable/11/contrib/sqlite3/tea/generic/tclsqlite3.c _U stable/12/ stable/12/contrib/sqlite3/Makefile.msc stable/12/contrib/sqlite3/configure stable/12/contrib/sqlite3/configure.ac stable/12/contrib/sqlite3/shell.c stable/12/contrib/sqlite3/sqlite3.c stable/12/contrib/sqlite3/sqlite3.h stable/12/contrib/sqlite3/sqlite3ext.h stable/12/contrib/sqlite3/tea/configure stable/12/contrib/sqlite3/tea/configure.ac stable/12/contrib/sqlite3/tea/generic/tclsqlite3.c Any idea when this will be available for people who prefer to track -RELEASE-p<n> versions? It's been over a week since I first saw a mention of it in my daily emails. (On 12.1-RELEASE-p6 here currently.) Ports updates have been committed to head and merged to quarterly base changes have been committed to head and merged to stable12 and stable11 ^Triage: Over to secteam@, pending Security Advisory (SA) and release bits. I have servers who don't report vulnerable packages: $ pkg info|grep sqlite3 sqlite3-3.31.1_1,1 $ pkg search sqlite3 sqlite3-3.32.2,1 $ pkg audit 0 problem(s) in 0 installed package(s) found. $ freebsd-version 12.1-RELEASE-p4 I can acknowledge this, my systems also show "0 problems" with "pkg audit -F" although they are vulnerable (pkg and base) On my systems, /usr/local/etc/periodic/security/405.pkg-base-audit has been reporting: FreeBSD-12.1_6 is vulnerable: several security issues in sqlite3 for 11 days now. The fixes have not trickled through to 12.1-RELEASE yet. The package version of the sqlite entry in vuln.xml is wrong. It has to be 3.32.2,1, including PORTEPOCH. Otherwise the pkg version match stuff will think that 3.32.2,1 is > than 3.32.2, which is the version of the package marked vulnerable. Created attachment 215933 [details]
correct most recent sqlite3 entry
the one-line diff
A commit references this bug: Author: zeising Date: Thu Jun 25 19:26:24 UTC 2020 New revision: 540402 URL: https://svnweb.freebsd.org/changeset/ports/540402 Log: vuln.xml: Adjust sqlite version in sqlite entry Update the sqlite versions affected in the latest sqlite entry. The entry failed to take PORTEPOCH into account, and without this fix pkg audit fails to mark sqlite as vulnerable when it's not updated to the latest version, since any version with PORTEPOCH set will always be greater than any version without. PR: 247149 Changes: head/security/vuxml/vuln.xml (In reply to commit-hook from comment #21) With that commit, my hosts are now correctly reporting that my installed sqlite3-3.31.1_1,1 is vulnerable Thank you. I'm hoping this fix makes it into freebsd-update so this can be cleared: [dan@r720-01:~] $ sudo /usr/local/etc/periodic/security/405.pkg-base-audit Checking for security vulnerabilities in base (userland & kernel): Host system: Database fetched: Thu Jun 25 20:37:32 UTC 2020 0 problem(s) in 0 installed package(s) found. FreeBSD-12.1_6 is vulnerable: several security issues in sqlite3 CVE: CVE-2020-13632 CVE: CVE-2020-13631 CVE: CVE-2020-13630 CVE: CVE-2020-13435 CVE: CVE-2020-13434 CVE: CVE-2020-11655 WWW: https://vuxml.FreeBSD.org/freebsd/c4ac9c79-ab37-11ea-8b5e-b42e99a1b9c3.html 1 problem(s) in 1 installed package(s) found. Any update? It's been over 3 weeks and I'd really like not to train myself to ignore daily reports of security problems in base, but I don't have the resources to track and compile 12-STABLE, so I'm stuck. :-( Alert fatigue is real. When in releng/{11.3,11.4,12.1}? We can include this in the next batch of security advisories / errata. (hat: security-officer secretary) (In reply to Philip Paeps from comment #26) So, obvious question there: when is that next batch planned for? Current thinking is next Tuesday. (In reply to Philip Paeps from comment #28) Any update? I was premature. This slipped into the next batch. I'm sorry. We'll push these fixes as soon as possible. (In reply to Philip Paeps from comment #30) It's been 10 days. I'd like a firm deadline with a credible commitment to it, not a vague promise like "as soon as possible". This is staged for the next batch security release. Note that the sqlite3 we have in the base system is a very unlikely vector of exploitation and is very isolated. Third party applications can't (easily) link with it. The base system components that do link with it are not likely targets for exploitation either. (In reply to Gordon Tetlow from comment #32) Thanks for the explanation. I appreciate that, and so do, I suspect, others waiting for -p<n>. Everyone with security/base-audit is being alerted to this issue. Alert fatigue is setting in. Every Wednesday I reset the alerts on my base-audit to keep quiet for another week. I suggest that if it's not urgent to patch, it's not urgent to lodge the vuln. Given that, as Gordon mentioned in comment #32, the version of sqlite3 in base is not a very attractive exploit vector, it would have been better not to list FreeBSD base in the vuxml. This can be a lesson for a future similar scenario. In general, secteam only documents vulnerabilities in FreeBSD in vuxml when we release the advisories. For issues like this, I'd be happy to add FreeBSD to the packages affected after we patch them too. (In reply to Philip Paeps from comment #36) I will push back next time anyone from secteam asks for a vuxml entry. I'm with jbeich@ on vuxml. as a side note: in the meantime, CVE-2020-15358 was discovered in sqlite 3.32.2 and before (minor severity, https://www.sqlite.org/src/tktview?name=8f157e8010) (In reply to Philip Paeps from comment #36) Perhaps I'm misunderstanding what you say. Are you saying that the lesson secteam should draw from this is "document the vulnerability later so it can happen at the same time as/closer in time to the time we're ready to issue -p<n> releases"? (In reply to Dan Langille from comment #40) That fixed my first host. Thank you. Finally! Thanks. I'd welcome a *public* discussion with *public* input on how to keep those delays in check. 7 weeks between -stable and -release is much too long IMO, no matter what your estimate of the bug's impact is and what else happened meanwhile. (In reply to PauAmma from comment #42) I fully agree FreeBSD base system patched as: ``` 2020-06-15 03:10:53 UTC (stable/12, 12.1-STABLE) 2020-08-05 17:13:08 UTC (releng/12.1, 12.1-RELEASE-p8) 2020-06-15 03:10:53 UTC (stable/11, 11.4-STABLE) 2020-08-05 17:13:08 UTC (releng/11.4, 11.4-RELEASE-p2) 2020-08-05 17:13:08 UTC (releng/11.3, 11.3-RELEASE-p12) ``` Security advisory released: https://security.FreeBSD.org/advisories/FreeBSD-SA-20:21.sqlite.asc Corrections committed to security/vuxml in r544259. |
Created attachment 215423 [details] vuxml patch to inform users about sqlite3 issues sqlite3 released version 3.32 fixing various vulnerabilities