Jump to:
Maintain row-security status properly in cached plans (Stephen Frost)
In a session that performs queries as more than one role, the plan cache might incorrectly re-use a plan that was generated for another role ID, thus possibly applying the wrong set of policies when row-level security (RLS) is in use. (CVE-2016-2193)
Add must-be-superuser checks to some new contrib/pageinspect functions (Andreas Seltenreich)
Most functions in the pageinspect extension that inspect bytea values disallow calls by non-superusers, but brin_page_type() and brin_metapage_info() failed to do so. Passing contrived bytea values to them might crash the server or disclose a few bytes of server memory. Add the missing permissions checks to prevent misuse. (CVE-2016-3065)
Ensure that INSERT ... ON CONFLICT DO UPDATE checks table permissions and RLS policies in all cases (Dean Rasheed)
The update path of INSERT ... ON CONFLICT DO UPDATE requires SELECT permission on the columns of the arbiter index, but it failed to check for that in the case of an arbiter specified by constraint name. In addition, for a table with row level security enabled, it failed to check updated rows against the table's SELECT policies (regardless of how the arbiter index was specified). (CVE-2017-15099)
Fix processing of partition keys containing multiple expressions (Álvaro Herrera, David Rowley)
This error led to crashes or, with carefully crafted input, disclosure of arbitrary backend memory. (CVE-2018-1052)
Document how to configure installations and applications to guard against search-path-dependent trojan-horse attacks from other users (Noah Misch)
Using a search_path setting that includes any schemas writable by a hostile user enables that user to capture control of queries and then run arbitrary SQL code with the permissions of the attacked user. While it is possible to write queries that are proof against such hijacking, it is notationally tedious, and it's very easy to overlook holes. Therefore, we now recommend configurations in which no untrusted schemas appear in one's search path. Relevant documentation appears in Section 5.8.6 (for database administrators and users), Section 33.1 (for application authors), Section 37.15.1 (for extension authors), and CREATE FUNCTION (for authors of SECURITY DEFINER functions). (CVE-2018-1058)
Remove public execute privilege from contrib/adminpack's pg_logfile_rotate() function (Stephen Frost)
pg_logfile_rotate() is a deprecated wrapper for the core function pg_rotate_logfile(). When that function was changed to rely on SQL privileges for access control rather than a hard-coded superuser check, pg_logfile_rotate() should have been updated as well, but the need for this was missed. Hence, if adminpack is installed, any user could request a logfile rotation, creating a minor security issue.
After installing this update, administrators should update adminpack by performing ALTER EXTENSION adminpack UPDATE in each database in which adminpack is installed. (CVE-2018-1115)
Fix INSERT ... ON CONFLICT UPDATE through a view that isn't just SELECT * FROM ... (Dean Rasheed, Amit Langote)
Erroneous expansion of an updatable view could lead to crashes or “attribute ... has the wrong type” errors, if the view's SELECT list doesn't match one-to-one with the underlying table's columns. Furthermore, this bug could be leveraged to allow updates of columns that an attacking user lacks UPDATE privilege for, if that user has INSERT and UPDATE privileges for some other column(s) of the table. Any user could also use it for disclosure of server memory. (CVE-2018-10925)
Ensure proper quoting of transition table names when pg_dump emits CREATE TRIGGER ... REFERENCING commands (Tom Lane)
This oversight could be exploited by an unprivileged user to gain superuser privileges during the next dump/reload or pg_upgrade run. (CVE-2018-16850)
Prevent row-level security policies from being bypassed via selectivity estimators (Dean Rasheed)
Some of the planner's selectivity estimators apply user-defined operators to values found in pg_statistic (e.g., most-common values). A leaky operator therefore can disclose some of the entries in a data column, even if the calling user lacks permission to read that column. In CVE-2017-7484 we added restrictions to forestall that, but we failed to consider the effects of row-level security. A user who has SQL permission to read a column, but who is forbidden to see certain rows due to RLS policy, might still learn something about those rows' contents via a leaky operator. This patch further tightens the rules, allowing leaky operators to be applied to statistics data only when there is no relevant RLS policy. (CVE-2019-10130)
Avoid access to already-freed memory during partition routing error reports (Michael Paquier)
This mistake could lead to a crash, and in principle it might be possible to use it to disclose server memory contents. (CVE-2019-10129)
Fix buffer-overflow hazards in SCRAM verifier parsing (Jonathan Katz, Heikki Linnakangas, Michael Paquier)
Any authenticated user could cause a stack-based buffer overflow by changing their own password to a purpose-crafted value. In addition to the ability to crash the PostgreSQL server, this could suffice for executing arbitrary code as the PostgreSQL operating system account.
A similar overflow hazard existed in libpq, which could allow a rogue server to crash a client or perhaps execute arbitrary code as the client's operating system account.
The PostgreSQL Project thanks Alexander Lakhin for reporting this problem. (CVE-2019-10164)
Fix execution of hashed subplans that require cross-type comparison (Tom Lane, Andreas Seltenreich)
Hashed subplans used the outer query's original comparison operator to compare entries of the hash table. This is the wrong thing if that operator is cross-type, since all the hash table entries will be of the subquery's output type. For the set of hashable cross-type operators in core PostgreSQL, this mistake seems nearly harmless on 64-bit machines, but it can result in crashes or perhaps unauthorized disclosure of server memory on 32-bit machines. Extensions might provide hashable cross-type operators that create larger risks. (CVE-2019-10209)
Add missing permissions checks for ALTER ... DEPENDS ON EXTENSION (Álvaro Herrera)
Marking an object as dependent on an extension did not have any privilege check whatsoever. This oversight allowed any user to mark routines, triggers, materialized views, or indexes as droppable by anyone able to drop an extension. Require that the calling user own the specified object (and hence have privilege to drop it). (CVE-2020-1720)
Allow the planner to apply potentially-leaky tests to child-table statistics, if the user can read the corresponding column of the table that's actually named in the query (Dilip Kumar, Amit Langote)
This change fixes a performance problem for partitioned tables that was created by the fix for CVE-2017-7484. That security fix disallowed applying leaky operators to statistics for columns that the current user doesn't have permission to read directly. However, it's somewhat common to grant permissions only on the parent partitioned table and not bother to do so on individual partitions. In such cases, the user can read the column via the parent, so there's no point in this security restriction; it only results in poorer planner estimates than necessary.
Set a secure search_path in logical replication walsenders and apply workers (Noah Misch)
A malicious user of either the publisher or subscriber database could potentially cause execution of arbitrary SQL code by the role running replication, which is often a superuser. Some of the risks here are equivalent to those described in CVE-2018-1058, and are mitigated in this patch by ensuring that the replication sender and receiver execute with empty search_path settings. (As with CVE-2018-1058, that change might cause problems for under-qualified names used in replicated tables' DDL.) Other risks are inherent in replicating objects that belong to untrusted roles; the most we can do is document that there is a hazard to consider. (CVE-2020-14349)
Make contrib modules' installation scripts more secure (Tom Lane)
Attacks similar to those described in CVE-2018-1058 could be carried out against an extension installation script, if the attacker can create objects in either the extension's target schema or the schema of some prerequisite extension. Since extensions often require superuser privilege to install, this can open a path to obtaining superuser privilege. To mitigate this risk, be more careful about the search_path used to run an installation script; disable check_function_bodies within the script; and fix catalog-adjustment queries used in some contrib modules to ensure they are secure. Also provide documentation to help third-party extension authors make their installation scripts secure. This is not a complete solution; extensions that depend on other extensions can still be at risk if installed carelessly. (CVE-2020-14350)
⇑ Upgrade to 9.5.1 released on 2016-02-11 - docs
⇑ Upgrade to 9.5.2 released on 2016-03-31 - docs
Maintain row-security status properly in cached plans (Stephen Frost)
In a session that performs queries as more than one role, the plan cache might incorrectly re-use a plan that was generated for another role ID, thus possibly applying the wrong set of policies when row-level security (RLS) is in use. (CVE-2016-2193)
Add must-be-superuser checks to some new contrib/pageinspect functions (Andreas Seltenreich)
Most functions in the pageinspect extension that inspect bytea values disallow calls by non-superusers, but brin_page_type() and brin_metapage_info() failed to do so. Passing contrived bytea values to them might crash the server or disclose a few bytes of server memory. Add the missing permissions checks to prevent misuse. (CVE-2016-3065)
⇑ Upgrade to 9.5.4 released on 2016-08-11 - docs
⇑ Upgrade to 9.6.3 released on 2017-05-11 - docs
⇑ Upgrade to 9.6.4 released on 2017-08-10 - docs
⇑ Upgrade to 10.1 released on 2017-11-09 - docs
Ensure that INSERT ... ON CONFLICT DO UPDATE checks table permissions and RLS policies in all cases (Dean Rasheed)
The update path of INSERT ... ON CONFLICT DO UPDATE requires SELECT permission on the columns of the arbiter index, but it failed to check for that in the case of an arbiter specified by constraint name. In addition, for a table with row level security enabled, it failed to check updated rows against the table's SELECT policies (regardless of how the arbiter index was specified). (CVE-2017-15099)
⇑ Upgrade to 10.2 released on 2018-02-08 - docs
Fix processing of partition keys containing multiple expressions (Álvaro Herrera, David Rowley)
This error led to crashes or, with carefully crafted input, disclosure of arbitrary backend memory. (CVE-2018-1052)
⇑ Upgrade to 10.3 released on 2018-03-01 - docs
Document how to configure installations and applications to guard against search-path-dependent trojan-horse attacks from other users (Noah Misch)
Using a search_path setting that includes any schemas writable by a hostile user enables that user to capture control of queries and then run arbitrary SQL code with the permissions of the attacked user. While it is possible to write queries that are proof against such hijacking, it is notationally tedious, and it's very easy to overlook holes. Therefore, we now recommend configurations in which no untrusted schemas appear in one's search path. Relevant documentation appears in Section 5.8.6 (for database administrators and users), Section 33.1 (for application authors), Section 37.15.1 (for extension authors), and CREATE FUNCTION (for authors of SECURITY DEFINER functions). (CVE-2018-1058)
⇑ Upgrade to 10.4 released on 2018-05-10 - docs
Remove public execute privilege from contrib/adminpack's pg_logfile_rotate() function (Stephen Frost)
pg_logfile_rotate() is a deprecated wrapper for the core function pg_rotate_logfile(). When that function was changed to rely on SQL privileges for access control rather than a hard-coded superuser check, pg_logfile_rotate() should have been updated as well, but the need for this was missed. Hence, if adminpack is installed, any user could request a logfile rotation, creating a minor security issue.
After installing this update, administrators should update adminpack by performing ALTER EXTENSION adminpack UPDATE in each database in which adminpack is installed. (CVE-2018-1115)
⇑ Upgrade to 10.5 released on 2018-08-09 - docs
Fix INSERT ... ON CONFLICT UPDATE through a view that isn't just SELECT * FROM ... (Dean Rasheed, Amit Langote)
Erroneous expansion of an updatable view could lead to crashes or “attribute ... has the wrong type” errors, if the view's SELECT list doesn't match one-to-one with the underlying table's columns. Furthermore, this bug could be leveraged to allow updates of columns that an attacking user lacks UPDATE privilege for, if that user has INSERT and UPDATE privileges for some other column(s) of the table. Any user could also use it for disclosure of server memory. (CVE-2018-10925)
⇑ Upgrade to 11.1 released on 2018-11-08 - docs
Ensure proper quoting of transition table names when pg_dump emits CREATE TRIGGER ... REFERENCING commands (Tom Lane)
This oversight could be exploited by an unprivileged user to gain superuser privileges during the next dump/reload or pg_upgrade run. (CVE-2018-16850)
⇑ Upgrade to 11.3 released on 2019-05-09 - docs
Prevent row-level security policies from being bypassed via selectivity estimators (Dean Rasheed)
Some of the planner's selectivity estimators apply user-defined operators to values found in pg_statistic (e.g., most-common values). A leaky operator therefore can disclose some of the entries in a data column, even if the calling user lacks permission to read that column. In CVE-2017-7484 we added restrictions to forestall that, but we failed to consider the effects of row-level security. A user who has SQL permission to read a column, but who is forbidden to see certain rows due to RLS policy, might still learn something about those rows' contents via a leaky operator. This patch further tightens the rules, allowing leaky operators to be applied to statistics data only when there is no relevant RLS policy. (CVE-2019-10130)
Avoid access to already-freed memory during partition routing error reports (Michael Paquier)
This mistake could lead to a crash, and in principle it might be possible to use it to disclose server memory contents. (CVE-2019-10129)
⇑ Upgrade to 11.4 released on 2019-06-20 - docs
Fix buffer-overflow hazards in SCRAM verifier parsing (Jonathan Katz, Heikki Linnakangas, Michael Paquier)
Any authenticated user could cause a stack-based buffer overflow by changing their own password to a purpose-crafted value. In addition to the ability to crash the PostgreSQL server, this could suffice for executing arbitrary code as the PostgreSQL operating system account.
A similar overflow hazard existed in libpq, which could allow a rogue server to crash a client or perhaps execute arbitrary code as the client's operating system account.
The PostgreSQL Project thanks Alexander Lakhin for reporting this problem. (CVE-2019-10164)
⇑ Upgrade to 11.5 released on 2019-08-08 - docs
Fix execution of hashed subplans that require cross-type comparison (Tom Lane, Andreas Seltenreich)
Hashed subplans used the outer query's original comparison operator to compare entries of the hash table. This is the wrong thing if that operator is cross-type, since all the hash table entries will be of the subquery's output type. For the set of hashable cross-type operators in core PostgreSQL, this mistake seems nearly harmless on 64-bit machines, but it can result in crashes or perhaps unauthorized disclosure of server memory on 32-bit machines. Extensions might provide hashable cross-type operators that create larger risks. (CVE-2019-10209)
⇑ Upgrade to 12.2 released on 2020-02-13 - docs
Add missing permissions checks for ALTER ... DEPENDS ON EXTENSION (Álvaro Herrera)
Marking an object as dependent on an extension did not have any privilege check whatsoever. This oversight allowed any user to mark routines, triggers, materialized views, or indexes as droppable by anyone able to drop an extension. Require that the calling user own the specified object (and hence have privilege to drop it). (CVE-2020-1720)
Allow the planner to apply potentially-leaky tests to child-table statistics, if the user can read the corresponding column of the table that's actually named in the query (Dilip Kumar, Amit Langote)
This change fixes a performance problem for partitioned tables that was created by the fix for CVE-2017-7484. That security fix disallowed applying leaky operators to statistics for columns that the current user doesn't have permission to read directly. However, it's somewhat common to grant permissions only on the parent partitioned table and not bother to do so on individual partitions. In such cases, the user can read the column via the parent, so there's no point in this security restriction; it only results in poorer planner estimates than necessary.
⇑ Upgrade to 12.4 released on 2020-08-13 - docs
Set a secure search_path in logical replication walsenders and apply workers (Noah Misch)
A malicious user of either the publisher or subscriber database could potentially cause execution of arbitrary SQL code by the role running replication, which is often a superuser. Some of the risks here are equivalent to those described in CVE-2018-1058, and are mitigated in this patch by ensuring that the replication sender and receiver execute with empty search_path settings. (As with CVE-2018-1058, that change might cause problems for under-qualified names used in replicated tables' DDL.) Other risks are inherent in replicating objects that belong to untrusted roles; the most we can do is document that there is a hazard to consider. (CVE-2020-14349)
Make contrib modules' installation scripts more secure (Tom Lane)
Attacks similar to those described in CVE-2018-1058 could be carried out against an extension installation script, if the attacker can create objects in either the extension's target schema or the schema of some prerequisite extension. Since extensions often require superuser privilege to install, this can open a path to obtaining superuser privilege. To mitigate this risk, be more careful about the search_path used to run an installation script; disable check_function_bodies within the script; and fix catalog-adjustment queries used in some contrib modules to ensure they are secure. Also provide documentation to help third-party extension authors make their installation scripts secure. This is not a complete solution; extensions that depend on other extensions can still be at risk if installed carelessly. (CVE-2020-14350)