Seq uses time-slice caching to speed up group by time() queries and a few others, in particular, those that drive Dashboards.
Behind the scenes, cache entries are keyed based on the clauses of the query, active signals, and so-on.
A bug in recent Seq versions up to 2021.2 causes the keys generated for in clauses to collide, when all elements of the detected set are constants.
For example:
select count(*) from stream where @Level in ['warn'] group by time(1m) and
select count(*) from stream where @Level in ['error', 'critical'] group by time(1m)
will generate the same cache key, and thus produce incorrect results when two cacheable queries differ only in this respect.
The bug is caused by inlining of arrays of constants: instead of ['warn'] generating an expression that constructs an array with a constant element, the array is precomputed and inlined as a constant itself.
The code that subsequently generates query cache keys does not properly account for this case.
Query cache entries will not collide if:
The queries do not group by time and are not executed from a dashboard,
The queries run over different signals,
Any other aspect of the query, including the select, where, group by, having, and order by clauses, differ in any way.
The text was updated successfully, but these errors were encountered:
nblumhardt
changed the title
Query cache collisions when queries differ only by in clause contents
CVE-2021-41329: Query cache collisions when queries differ only by in clause contents
Sep 20, 2021
Datalust requested a CVE number for this bug because of the possibility of query collisions exposing the query results of one user to another, when the data visible to the second user should be limited by their view filter.
The information exposure may occur when a query executed by a user with restricted access differs from an earlier query, executed by a user with different restrictions, only by the contents of an array or in clause that appears in the restricted user's view filter.
For example, if user 1 has view filter Project in ['project-1', 'project-2'] and user 2 has a view filter Project in ['project-3'], then each user may see cached results of a query select distinct(CustomerName) group by time(1h) belonging to the other user, if they execute these queries in turn.
We expect the real-world impact of this bug to be low because:
Only installations that restrict lower-permission users via view filters are affected,
Only view filters based on in clauses or arrays are affected,
Only group by time() and dashboard-based queries are affected,
Cache collisions require recent execution of an identical query with the same time bucketing, over an overlapping interval, with no further restrictions or operators applied.
If you need any assistance determining whether this issue is likely to have occurred on the Seq instances you manage, please reach out via our support address.
Seq uses time-slice caching to speed up
group by time()queries and a few others, in particular, those that drive Dashboards.Behind the scenes, cache entries are keyed based on the clauses of the query, active signals, and so-on.
A bug in recent Seq versions up to 2021.2 causes the keys generated for
inclauses to collide, when all elements of the detected set are constants.For example:
select count(*) from stream where @Level in ['warn'] group by time(1m)andselect count(*) from stream where @Level in ['error', 'critical'] group by time(1m)will generate the same cache key, and thus produce incorrect results when two cacheable queries differ only in this respect.
The bug is caused by inlining of arrays of constants: instead of
['warn']generating an expression that constructs an array with a constant element, the array is precomputed and inlined as a constant itself.The code that subsequently generates query cache keys does not properly account for this case.
Query cache entries will not collide if:
timeand are not executed from a dashboard,select,where,group by,having, andorder byclauses, differ in any way.The text was updated successfully, but these errors were encountered: