postgres

Author SHA1 Message Date

Author	SHA1	Message	Date
Tom Lane	7eeb1d9861	Make contrib modules' installation scripts more secure. Hostile objects located within the installation-time search_path could capture references in an extension's installation or upgrade script. If the extension is being installed with superuser privileges, this opens the door to privilege escalation. While such hazards have existed all along, their urgency increases with the v13 "trusted extensions" feature, because that lets a non-superuser control the installation path for a superuser-privileged script. Therefore, make a number of changes to make such situations more secure: * Tweak the construction of the installation-time search_path to ensure that references to objects in pg_catalog can't be subverted; and explicitly add pg_temp to the end of the path to prevent attacks using temporary objects. * Disable check_function_bodies within installation/upgrade scripts, so that any security gaps in SQL-language or PL-language function bodies cannot create a risk of unwanted installation-time code execution. * Adjust lookup of type input/receive functions and join estimator functions to complain if there are multiple candidate functions. This prevents capture of references to functions whose signature is not the first one checked; and it's arguably more user-friendly anyway. * Modify various contrib upgrade scripts to ensure that catalog modification queries are executed with secure search paths. (These are in-place modifications with no extension version changes, since it is the update process itself that is at issue, not the end result.) Extensions that depend on other extensions cannot be made fully secure by these methods alone; therefore, revert the "trusted" marking that commit `eb67623c9` applied to earthdistance and hstore_plperl, pending some better solution to that set of issues. Also add documentation around these issues, to help extension authors write secure installation scripts. Patch by me, following an observation by Andres Freund; thanks to Noah Misch for review. Security: CVE-2020-14350	5 years ago
Robert Haas	2910fc8239	Update extensions with GIN/GIST support for parallel query. Commit `749a787c5b` bumped the extension version on all of these extensions already, and we haven't had a release since then, so we can make further changes without bumping the extension version again. Take this opportunity to mark all of the functions exported by these modules PARALLEL SAFE -- except for pg_trgm's set_limit(). Mark that one PARALLEL RESTRICTED, because it makes a persistent change to a GUC value. Note that some of the markings added by this commit don't have any effect; for example, gseg_picksplit() isn't likely to be mentioned explicitly in a query and therefore it's parallel-safety marking will never be consulted. But this commit just marks everything for consistency: if it were somehow used in a query, that would be fine as far as parallel query is concerned, since it does not consult any backend-private state, attempt to write data, etc. Andreas Karlsson, with a few revisions by me.	9 years ago
Tom Lane	749a787c5b	Handle contrib's GIN/GIST support function signature changes honestly. In commits `9ff60273e3` and `dbe2328959` I (tgl) fixed the signatures of a bunch of contrib's GIN and GIST support functions so that they would pass validation by the recently-added amvalidate functions. The backend does not actually consult or check those signatures otherwise, so I figured this was basically cosmetic and did not require an extension version bump. However, Alexander Korotkov pointed out that that would leave us in a pretty messy situation if we ever wanted to redefine those functions later, because there wouldn't be a unique way to name them. Since we're going to be bumping these extensions' versions anyway for parallel-query cleanups, let's take care of this now. Andreas Karlsson, adjusted for more search-path-safety by me	9 years ago

Tom Lane

Make contrib modules' installation scripts more secure.

Hostile objects located within the installation-time search_path could
capture references in an extension's installation or upgrade script.
If the extension is being installed with superuser privileges, this
opens the door to privilege escalation.  While such hazards have existed
all along, their urgency increases with the v13 "trusted extensions"
feature, because that lets a non-superuser control the installation path
for a superuser-privileged script.  Therefore, make a number of changes
to make such situations more secure:

* Tweak the construction of the installation-time search_path to ensure
that references to objects in pg_catalog can't be subverted; and
explicitly add pg_temp to the end of the path to prevent attacks using
temporary objects.

* Disable check_function_bodies within installation/upgrade scripts,
so that any security gaps in SQL-language or PL-language function bodies
cannot create a risk of unwanted installation-time code execution.

* Adjust lookup of type input/receive functions and join estimator
functions to complain if there are multiple candidate functions.  This
prevents capture of references to functions whose signature is not the
first one checked; and it's arguably more user-friendly anyway.

* Modify various contrib upgrade scripts to ensure that catalog
modification queries are executed with secure search paths.  (These
are in-place modifications with no extension version changes, since
it is the update process itself that is at issue, not the end result.)

Extensions that depend on other extensions cannot be made fully secure
by these methods alone; therefore, revert the "trusted" marking that
commit eb67623c9 applied to earthdistance and hstore_plperl, pending
some better solution to that set of issues.

Also add documentation around these issues, to help extension authors
write secure installation scripts.

Patch by me, following an observation by Andres Freund; thanks
to Noah Misch for review.

Security: CVE-2020-14350

5 years ago

Robert Haas

2910fc8239

Update extensions with GIN/GIST support for parallel query.

Commit 749a787c5b bumped the extension
version on all of these extensions already, and we haven't had a
release since then, so we can make further changes without bumping the
extension version again.  Take this opportunity to mark all of the
functions exported by these modules PARALLEL SAFE -- except for
pg_trgm's set_limit().  Mark that one PARALLEL RESTRICTED, because it
makes a persistent change to a GUC value.

Note that some of the markings added by this commit don't have any
effect; for example, gseg_picksplit() isn't likely to be mentioned
explicitly in a query and therefore it's parallel-safety marking will
never be consulted.  But this commit just marks everything for
consistency: if it were somehow used in a query, that would be fine as
far as parallel query is concerned, since it does not consult any
backend-private state, attempt to write data, etc.

Andreas Karlsson, with a few revisions by me.

9 years ago

Tom Lane

749a787c5b

Handle contrib's GIN/GIST support function signature changes honestly.

In commits 9ff60273e3 and dbe2328959 I (tgl) fixed the
signatures of a bunch of contrib's GIN and GIST support functions so that
they would pass validation by the recently-added amvalidate functions.
The backend does not actually consult or check those signatures otherwise,
so I figured this was basically cosmetic and did not require an extension
version bump.  However, Alexander Korotkov pointed out that that would
leave us in a pretty messy situation if we ever wanted to redefine those
functions later, because there wouldn't be a unique way to name them.
Since we're going to be bumping these extensions' versions anyway for
parallel-query cleanups, let's take care of this now.

Andreas Karlsson, adjusted for more search-path-safety by me

9 years ago

3 Commits (cf6f802bf538ab1c9c0ef60a6e9d6fafdfb06b98)