Bug 1841568 (CVE-2020-13631) - CVE-2020-13631 sqlite: Virtual table can be renamed into the name of one of its shadow tables
Summary: CVE-2020-13631 sqlite: Virtual table can be renamed into the name of one of i...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2020-13631
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1841569 1841570 1841571 1845474 1845475 1845476
Blocks: 1841236
TreeView+ depends on / blocked
 
Reported: 2020-05-29 13:29 UTC by Guilherme de Almeida Suckevicz
Modified: 2021-05-19 09:54 UTC (History)
13 users (show)

Fixed In Version: sqlite 3.32.0
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the virtual table implementation of SQLite. This flaw allows an attacker who can execute SQL statements to rename a virtual table to the name of one of its shadow tables, leading to potential data corruption.
Clone Of:
Environment:
Last Closed: 2020-11-04 02:25:36 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:4442 0 None None None 2020-11-04 00:59:53 UTC

Description Guilherme de Almeida Suckevicz 2020-05-29 13:29:09 UTC
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.

Reference and upstream commit:
https://sqlite.org/src/info/eca0ba2cf4c0fdf7

Comment 1 Guilherme de Almeida Suckevicz 2020-05-29 13:29:40 UTC
Created mingw-sqlite tracking bugs for this issue:

Affects: fedora-all [bug 1841569]


Created sqlite tracking bugs for this issue:

Affects: fedora-all [bug 1841571]


Created sqlite2 tracking bugs for this issue:

Affects: fedora-all [bug 1841570]

Comment 4 Mauro Matteo Cascella 2020-06-09 14:18:01 UTC
https://www.sqlite.org/vtab.html#xshadowname:
"""
Some virtual table implementations (ex: FTS3, FTS5, and RTREE) make use of real (non-virtual) database tables to store content. For example, when content is inserted into the FTS3 virtual table, the data is ultimately stored in real tables named "%_content", "%_segdir", "%_segments", "%_stat", and "%_docsize" where "%" is the name of the original virtual table. This auxiliary real tables that store content for a virtual table are called shadow tables.
"""

My understanding is that a virtual table is not supposed to be renamed to one of its shadow tables to avoid possible corruption of the underlying data. SQLite needs to differentiate a virtual table from its shadow tables in order to protect the content of the shadow tables from being corrupted (although it's not clear to me what a concrete attack scenario would look like). Anyway, to exploit this issue an attacker would need to have a level of access that allows him to execute SQL statements to rename the virtual tables.

Comment 5 errata-xmlrpc 2020-11-04 00:59:52 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2020:4442 https://access.redhat.com/errata/RHSA-2020:4442

Comment 6 Product Security DevOps Team 2020-11-04 02:25:36 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2020-13631

Comment 7 errata-xmlrpc 2021-05-18 16:30:11 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:1968 https://access.redhat.com/errata/RHSA-2021:1968


Note You need to log in before you can comment on or make changes to this bug.