Bug 1841568 (CVE-2020-13631)
| Summary: | CVE-2020-13631 sqlite: Virtual table can be renamed into the name of one of its shadow tables | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Guilherme de Almeida Suckevicz <gsuckevi> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | alex, databases-maint, drizt72, erik-fedora, fedora, itamar, mschorm, odubaj, pkubat, praiskup, rh-spice-bugs, rjones, wilmer5 |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 02:25:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1841569, 1841570, 1841571, 1845474, 1845475, 1845476 | ||
| Bug Blocks: | 1841236 | ||
|
Description
Guilherme de Almeida Suckevicz
2020-05-29 13:29:09 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] 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. 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 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 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 |