IVM Development Group have released  [pg_ivm 1.5.1]( 
https://github.com/sraoss/pg_ivm/releases/tag/v1.5.1 ) to address security 
issues: CVE-2023-22847, CVE-2023-23554.

### Security issues

* Exposure of sensitive information to an unauthorized actor (CWE-200) - 
[CVE-2023-22847](https://www.cve.org/CVERecord?id=CVE-2023-22847)
    An Incrementally Maintainable Materialized View (IMMV) created by pg_ivm 
may reflect rows with Row-Level Security that the owner of the IMMV should not 
have access to.

* Uncontrolled search path element (CWE-427) - 
[CVE-2023-23554](https://www.cve.org/CVERecord?id=CVE-2023-23554)
    When refreshing an IMMV, pg_ivm executes functions without specifying 
schema names. Under certain conditions, pg_ivm may be tricked to execute 
unexpected functions from other schemas with the IMMV owner's privilege.

### Bug fixes
* Fix row level security checks during view maintenance (Yugo Nagata)  
(CVE-2023-22847)
    
    The view maintenance is performed under the view owner privilege. If a 
modified table has a (Row Level Security) RLS policy, rows in that table must 
be accessed by the privilege of the IMMV owner during view maintenance, so rows 
invisible to the view owner must not appear in the IMMV.  However, the security 
check was not properly handled, and rows that must not be accessed from the 
view owner could appear in the view contents when the view was refreshed 
incrementally during a query that contains multiple types of commands, like a 
modifying CTE that contains INSERT and UPDATE, or a MERGE command.
    
* Fix to use qualified function names during maintenance (Yugo Nagata)  
(CVE-2023-23554)
    
    Previously, functions names in pg_catalog schema that were used during view 
maintenance were not qualified. This is problematic because functions in other 
schema could be referenced unintentionally. Moreover, that could result in 
privilege escalation that if a nefarious user who can create a function, 
arbitrary functions could be executed under IMMV owner's privilege.

* Rebuild the query for recalculating min/max after search_path change (Yugo 
Nagata)  (CVE-2023-23554)
    
    Cached plans for recalculating min/max values are built from the view 
definition query text. Therefore, when the search_path was changed, the query 
text was analyzed again, and tables or functions in a wrong schema could be 
referenced in the plan. This is fixed so that, after search_path is changed, a 
plan is rebuilt from a new query string where table / function names are 
properly qualified under the latest search_path are used.

**Full Changelog**: https://github.com/sraoss/pg_ivm/compare/v1.5...v1.5.1

### About pg_ivm

pg_ivm is an extension module that provides Incremental View Maintenance (IVM) 
feature.

Incremental View Maintenance (IVM) is a way to make materialized views 
up-to-date in
which only incremental changes are computed and applied on views rather than 
recomputing. 
pg_ivm provides a kind of immediate maintenance, in which materialized views 
are updated
immediately after a base table is modified.
 
Source repository: 
[https://github.com/sraoss/pg_ivm](https://github.com/sraoss/pg_ivm)

Reply via email to