database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-19 13:42:17 +03:00
Code Activity

Make relation-enumerating operations be security-restricted operations.

Browse Source 
When a feature enumerates relations and runs functions associated with
all found relations, the feature's user shall not need to trust every
user having permission to create objects.  BRIN-specific functionality
in autovacuum neglected to account for this, as did pg_amcheck and
CLUSTER.  An attacker having permission to create non-temp objects in at
least one schema could execute arbitrary SQL functions under the
identity of the bootstrap superuser.  CREATE INDEX (not a
relation-enumerating operation) and REINDEX protected themselves too
late.  This change extends to the non-enumerating amcheck interface.
Back-patch to v10 (all supported versions).

Sergey Shinderuk, reviewed (in earlier versions) by Alexander Lakhin.
Reported by Alexander Lakhin.

Security: CVE-2022-1552
This commit is contained in:
Noah Misch
2022-05-09 08:35:08 -07:00
parent f45f8b7ff3
commit a117cebd63
10 changed files with 378 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
src/backend/utils/init/miscinit.c
View File

@@ -567,15 +567,21 @@ GetAuthenticatedUserId(void)
* with guc.c's internal state, so SET ROLE has to be disallowed.
*
* SECURITY_RESTRICTED_OPERATION indicates that we are inside an operation
* that does not wish to trust called user-defined functions at all. This
* bit prevents not only SET ROLE, but various other changes of session state
* that normally is unprotected but might possibly be used to subvert the
* calling session later. An example is replacing an existing prepared
* statement with new code, which will then be executed with the outer
* session's permissions when the prepared statement is next used. Since
* these restrictions are fairly draconian, we apply them only in contexts
* where the called functions are really supposed to be side-effect-free
* anyway, such as VACUUM/ANALYZE/REINDEX.
* that does not wish to trust called user-defined functions at all. The
* policy is to use this before operations, e.g. autovacuum and REINDEX, that
* enumerate relations of a database or schema and run functions associated
* with each found relation. The relation owner is the new user ID. Set this
* as soon as possible after locking the relation. Restore the old user ID as
* late as possible before closing the relation; restoring it shortly after
* close is also tolerable. If a command has both relation-enumerating and
* non-enumerating modes, e.g. ANALYZE, both modes set this bit. This bit
* prevents not only SET ROLE, but various other changes of session state that
* normally is unprotected but might possibly be used to subvert the calling
* session later. An example is replacing an existing prepared statement with
* new code, which will then be executed with the outer session's permissions
* when the prepared statement is next used. These restrictions are fairly
* draconian, but the functions called in relation-enumerating operations are
* really supposed to be side-effect-free anyway.
*
* SECURITY_NOFORCE_RLS indicates that we are inside an operation which should
* ignore the FORCE ROW LEVEL SECURITY per-table indication. This is used to