The PostgreSQL Global Development Group has released an update to all supported versions of our database system, including 13.1, 12.5, 11.10, 10.15, 9.6.20, and 9.5.24. This release closes three security vulnerabilities and fixes over 65 bugs reported over the last three months.
Due to the nature of CVE-2020-25695, we advise you to update as soon as possible.
Additionally, this is the second-to-last release of PostgreSQL 9.5. If you are running PostgreSQL 9.5 in a production environment, we suggest that you make plans to upgrade.
For the full list of changes, please review the release notes.
Versions Affected: 9.5 - 13. The security team typically does not test unsupported versions, but this problem is quite old.
An attacker having permission to create non-temporary objects in at least one schema can execute arbitrary SQL functions under the identity of a superuser.
While promptly updating PostgreSQL is the best remediation for most users, a
user unable to do that can work around the vulnerability by disabling
autovacuum and not manually running ANALYZE, CLUSTER, REINDEX,
CREATE INDEX, VACUUM FULL, REFRESH MATERIALIZED VIEW, or a restore from
output of the pg_dump command. Performance may degrade quickly under this
workaround.
VACUUM without the FULL option is safe, and all commands are fine when a
trusted user owns the target object.
The PostgreSQL project thanks Etienne Stalmans for reporting this problem.
Versions Affected: 9.5 - 13. The security team typically does not test unsupported versions, but this problem is quite old.
Many PostgreSQL-provided client applications have options that create additional
database connections. Some of those applications reuse only the basic
connection parameters (e.g. host, user, port), dropping others. If this
drops a security-relevant parameter (e.g. channel_binding, sslmode,
requirepeer, gssencmode), the attacker has an opportunity to complete a MITM
attack or observe cleartext transmission.
Affected applications are clusterdb, pg_dump, pg_restore, psql,
reindexdb, and vacuumdb. The vulnerability arises only if one invokes an
affected client application with a connection string containing a
security-relevant parameter.
This also fixes how the \connect command of psql reuses connection
parameters, i.e. all non-overridden parameters from a previous connection
string now re-used.
The PostgreSQL project thanks Peter Eisentraut for reporting this problem.
psql's \gset allows overwriting specially treated variablesVersions Affected: 9.5 - 13. The security team typically does not test unsupported versions, but this problem likely arrived with the feature's debut in version 9.3.
The \gset meta-command, which sets psql variables based on query results,
does not distinguish variables that control psql behavior. If an interactive
psql session uses \gset when querying a compromised server, the attacker can
execute arbitrary code as the operating system account running psql.
Using \gset with a prefix not found among specially treated variables, e.g.
any lowercase string, precludes the attack in an unpatched psql.
The PostgreSQL project thanks Nick Cleaton for reporting this problem.
This update also fixes over 65 bugs that were reported in the last several months. Some of these issues only affect version 13, but may also apply to other supported versions.
Some of these fixes include:
START_REPLICATION.fsync is called on the SLRU caches that PostgreSQL maintains. This
prevents potential data loss due to an operating system crash.ALTER ROLE usage for users with the BYPASSRLS permission.ALTER TABLE ONLY ... DROP EXPRESSION is disallowed on partitioned tables
when there are child tables.ALTER TABLE ONLY ... ENABLE/DISABLE TRIGGER does not apply to
child tables.ALTER TABLE ... SET NOT NULL on partitioned tables to avoid a
potential deadlock in parallel pg_restore.CREATE TABLE LIKE with inheritance.DROP INDEX CONCURRENTLY is disallowed on partitioned tables.LOCK TABLE to succeed on a self-referential view instead of throwing
an error.REINDEX CONCURRENTLY.GENERATED columns are updated when any columns they depend on
are updated via a rule or an updatable view..datetime() method to accept ISO 8601-format timestamps.REINDEX on the index.EXPLAIN to have the correct XML tag nesting for
incremental sort plans.CALL with PL/pgSQL, SIGHUP processing a configuration parameter that cannot
be applied without a restart, and an edge-case for index lookup for a partition.psql now reads the output of a backtick command in text mode,
not binary mode, so it can now properly handle newlines.pg_dump, pg_restore, clusterdb, reindexdb, and vacuumdb use
complex connection-string parameters.\connect command of psql reuses connection parameters, ensure
that all non-overridden parameters from a previous connection string are also
re-used.pg_dump collects per-column information about extension
configuration tables, avoiding crashes when specifying --inserts.pg_restore processes foreign keys referencing
partitioned tables in the correct order.contrib/pgcrypto, including a memory leak fix.This update also contains tzdata release 2020d for for DST law changes in Fiji, Morocco, Palestine, the Canadian Yukon, Macquarie Island, and Casey Station (Antarctica); plus historical corrections for France, Hungary, Monaco, and Palestine.
For the full list of changes available, please review the release notes.
PostgreSQL 9.5 will stop receiving fixes on February 11, 2021. If you are running PostgreSQL 9.5 in a production environment, we suggest that you make plans to upgrade to a newer, supported version of PostgreSQL. Please see our versioning policy for more information.
All PostgreSQL update releases are cumulative. As with other minor releases,
users are not required to dump and reload their database or use pg_upgrade in
order to apply this update release; you may simply shutdown PostgreSQL and
update its binaries.
Users who have skipped one or more update releases may need to run additional, post-update steps; please see the release notes for earlier versions for details.
For more details, please see the release notes.
NOTE: PostgreSQL 9.5 will stop receiving fixes on February 11, 2021. Please see our versioning policy for more information.