Bug 1924886 (CVE-2021-20227) - CVE-2021-20227 sqlite: potential use-after-free bug when processing a subquery with both a correlated WHERE clause and a "HAVING 0" clause and where the parent query is an aggregate
Summary: CVE-2021-20227 sqlite: potential use-after-free bug when processing a subque...
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2021-20227
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: 1924905 1924906 1924914 1924915
Blocks: 1919824
TreeView+ depends on / blocked
 
Reported: 2021-02-03 20:10 UTC by Todd Cullum
Modified: 2021-05-27 17:32 UTC (History)
12 users (show)

Fixed In Version: sqlite 3.34.1
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in SQLite's SELECT query functionality (src/select.c). This flaw allows an attacker who is capable of running SQL queries locally on the SQLite database to cause a denial of service or possible code execution by triggering a use-after-free. The highest threat from this vulnerability is to system availability.
Clone Of:
Environment:
Last Closed: 2021-05-27 17:32:03 UTC
Embargoed:


Attachments (Terms of Use)

Description Todd Cullum 2021-02-03 20:10:19 UTC
SQLite 3.34.1 fixes a potential use-after-free bug when processing a subquery with both a correlated WHERE clause and a "HAVING 0" clause and where the parent query is an aggregate.

References:

https://sqlite.org/src/info/30a4c323650cc949
https://www.sqlite.org/releaselog/3_34_1.html

Comment 1 Todd Cullum 2021-02-03 20:40:58 UTC
Technical summary:

From [1]:

"The WHERE clause (a=2), uses an aggregate column from the outer query.
If the HAVING term (0) is moved into the WHERE clause in this case,
SQLite would at one point optimize (a=2 AND 0) to simply (0). Which
is logically correct, but happened to cause problems in aggregate
processing for the outer query."

To ensure that the condition HAVING 0 is considered, the upstream patch adds the ExprAlwaysFalse(pExpr)==0 check to the if statement before the business logic in havingToWhereExprCb() in file src/select.c.

This flaw could allow an attacker who has permission to run SQL queries on the sqlite database to cause a denial of service, or possibly code execution if they are able to control the re-used memory.

This flaw has been marked Moderate because in order to run such a query, a user would need to already have access to query the data in the database.

1. https://sqlite.org/src/info/30a4c323650cc949

Comment 4 Todd Cullum 2021-02-03 20:58:16 UTC
External References:

https://www.sqlite.org/releaselog/3_34_1.html

Comment 5 Todd Cullum 2021-02-03 20:58:49 UTC
Mitigation:

Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.

Comment 7 Todd Cullum 2021-02-03 21:09:57 UTC
Created mingw-sqlite tracking bugs for this issue:

Affects: fedora-all [bug 1924915]


Created sqlite tracking bugs for this issue:

Affects: fedora-all [bug 1924914]

Comment 13 RaTasha Tillery-Smith 2021-02-09 18:40:11 UTC
Statement:

SQLite as shipped in Red Hat Enterprise Linux 6, 7 and 8 is not affected by this flaw as the code was introduced in a newer version of SQLite than that shipped. This flaw has been marked Moderate because in order to run such a query, a user would need to already have access to query the data in the database.

Comment 14 Product Security DevOps Team 2021-05-27 17:32:03 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-2021-20227


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