[ASA-202011-14] postgresql: multiple issues
foxboron at archlinux.org
Thu Nov 26 19:35:52 UTC 2020
Arch Linux Security Advisory ASA-202011-14
Date : 2020-11-17
CVE-ID : CVE-2020-25694 CVE-2020-25695 CVE-2020-25696
Package : postgresql
Type : multiple issues
Remote : Yes
Link : https://security.archlinux.org/AVG-1276
The package postgresql before version 12.5-1 is vulnerable to multiple
issues including sandbox escape, arbitrary code execution and silent
Upgrade to 12.5-1.
# pacman -Syu "postgresql>=12.5-1"
The problems have been fixed upstream in version 12.5.
- CVE-2020-25694 (silent downgrade)
A security issue has been found in PostgreSQL before 12.5. 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
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
- CVE-2020-25695 (sandbox escape)
A security issue has been found in PostgreSQL before 12.5, where an
attacker having permission to create non-temporary objects in at least
one schema can execute arbitrary SQL functions under the identity of a
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.
- CVE-2020-25696 (arbitrary code execution)
A security issue has been found in PostgreSQL before 12.5, where psql's
\gset allows overwriting specially treated variables. 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.
An attacker in position of man-in-the-middle might be able to access
sensitive information or even alter SQL commands. A remote,
authenticated attacker might be able to escape the PG sandbox and
execute arbitrary code on the server.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the arch-security