Bug 754363 (CVE-2020-25694, CVE-2020-25695, CVE-2020-25696) – <dev-db/postgresql-{13.1,12.5,11.10,10.15,9.6.20,9.5.24} Multiple Vulnerabilities (CVE-2020-{25695,25694,25696})

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Aaron W. Swenson 2020-11-14 13:44:08 UTC]

PostgreSQL versions prior to 13.1, 12.5, 11.10, 10.15, 9.6.20, and 9.5.24 have multiple security issues. The worst of which allows an authenticated remote user to execute arbitrary SQL functions with superuser privileges.


A snippet for the news [1] item follows:
====================================================

CVE-2020-25695: Multiple features escape "security restricted operation" sandbox

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.
CVE-2020-25694: Reconnection can downgrade connection security settings

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.
CVE-2020-25696: psql's \gset allows overwriting specially treated variables

Versions 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.

====================================================
[1]: https://www.postgresql.org/about/news/postgresql-131-125-1110-1015-9620-and-9524-released-2111/

[Comment 1 Larry the Git Cow 2020-11-14 13:59:29 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=734742ccd7c2a901d5fb30975c0c7d27c6482cc2

commit 734742ccd7c2a901d5fb30975c0c7d27c6482cc2
Author:     Aaron W. Swenson <[e-mail]>
AuthorDate: 2020-11-14 13:50:18 +0000
Commit:     Aaron W. Swenson <[e-mail]>
CommitDate: 2020-11-14 13:59:10 +0000

    dev-db/postgresql: Version Bumps
    
    Bump to:
     - 13.1
     - 12.5
     - 11.10
     - 10.15
     - 9.6.20
     - 9.5.24
    
    Fixes CVE-2020-25695, CVE-2020-25694, and CVE-2020-25696.
    
    Pg 10+ includes a patch to fix building wit ICU 68.
    
    Bug: https://bugs.gentoo.org/753257
    Bug: https://bugs.gentoo.org/754363
    
    Signed-off-by: Aaron W. Swenson <[e-mail]>

 dev-db/postgresql/Manifest                         |   6 +
 .../postgresql/files/postgresql-10.0-icu68.patch   |  12 +
 dev-db/postgresql/postgresql-10.15.ebuild          | 459 ++++++++++++++++++++
 dev-db/postgresql/postgresql-11.10.ebuild          | 461 ++++++++++++++++++++
 dev-db/postgresql/postgresql-12.5.ebuild           | 461 ++++++++++++++++++++
 dev-db/postgresql/postgresql-13.1.ebuild           | 465 ++++++++++++++++++++
 dev-db/postgresql/postgresql-9.5.24.ebuild         | 476 ++++++++++++++++++++
 dev-db/postgresql/postgresql-9.6.20.ebuild         | 481 +++++++++++++++++++++
 dev-db/postgresql/postgresql-9999.ebuild           |   5 +
 9 files changed, 2826 insertions(+)

[Comment 2 John Helmert III 2020-11-14 15:55:11 UTC]

Thank you for the report. Please stabilize when ready

[Comment 3 Aaron W. Swenson 2020-11-15 18:01:25 UTC]

Please stabilize the following targets:
=dev-db/postgresql-10.15  ~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~sparc ~x86
=dev-db/postgresql-11.10  ~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~sparc ~x86
=dev-db/postgresql-12.5   ~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~sparc ~x86
=dev-db/postgresql-9.5.24 ~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~sparc ~x86
=dev-db/postgresql-9.6.20 ~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~sparc ~x86

How I test:

  for p in postgresql-?*.*.ebuild; do
    ebuild $p clean
    USE="-server" ebuild $p install # tests 
    ebuild $p clean
    USE="server" FEATURES="test userpriv" ebuild $p install
    ebuild $p clean
  done

[Comment 4 Sam James 2020-11-18 00:04:29 UTC]

Those versions seem to already be stabled?

[Comment 5 Aaron W. Swenson 2020-11-19 19:08:38 UTC]

(In reply to Sam James from comment #4)
> Those versions seem to already be stabled?

I've made an error in the version bump commit.

I did run repoman, but must have done that in the wrong directory. This is possible because I get the bump in advance of the announcement, and keep the bumped ebuilds separate from Gentoo repo until upstream makes the announcement.  My son was just starting to stir so I got in a hurry when I copied the bump over. pkgcheck didn't raise an issue after, either.

What's the best course of action at this point? I'm hesitant to just flip the keywords.

[Comment 6 Thomas Deutschmann (RETIRED) 2020-11-19 19:52:10 UTC]

UnCC'ing arches -- committed directly to stable.

New GLSA request filed.

At this point it is too late. Flipping keywords would cause downgrades.
Let's hope that there are no failures.

Please proceed with cleanup.

[Comment 7 Larry the Git Cow 2020-11-20 16:49:37 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3099bcf4caafc9b2a972a8a3380ec9f616225996

commit 3099bcf4caafc9b2a972a8a3380ec9f616225996
Author:     Aaron W. Swenson <[e-mail]>
AuthorDate: 2020-11-20 16:46:43 +0000
Commit:     Aaron W. Swenson <[e-mail]>
CommitDate: 2020-11-20 16:46:43 +0000

    dev-db/postgresql: Cleanup
    
    Bug: https://bugs.gentoo.org/754363
    
    Signed-off-by: Aaron W. Swenson <[e-mail]>

 dev-db/postgresql/postgresql-10.14.ebuild  | 456 ---------------------------
 dev-db/postgresql/postgresql-11.9.ebuild   | 458 ---------------------------
 dev-db/postgresql/postgresql-12.4.ebuild   | 458 ---------------------------
 dev-db/postgresql/postgresql-13.0.ebuild   | 458 ---------------------------
 dev-db/postgresql/postgresql-9.5.23.ebuild | 476 ----------------------------
 dev-db/postgresql/postgresql-9.6.19.ebuild | 481 -----------------------------
 6 files changed, 2787 deletions(-)

[Comment 8 Aaron W. Swenson 2020-11-20 17:02:39 UTC]

(In reply to Thomas Deutschmann from comment #6)
> UnCC'ing arches -- committed directly to stable.
> 
> New GLSA request filed.
> 
> At this point it is too late. Flipping keywords would cause downgrades.
> Let's hope that there are no failures.
> 
> Please proceed with cleanup.

There haven't been any reports since I've introduced the bumps. I may have gotten lucky this time.

I have figured out how to get repoman to run as a pre-commit hook, now. So, it's unlikely to happen again.

[Comment 9 Sam James 2020-11-24 02:59:23 UTC]

(In reply to Aaron W. Swenson from comment #8)
> (In reply to Thomas Deutschmann from comment #6)
> > UnCC'ing arches -- committed directly to stable.
> > 
> > New GLSA request filed.
> > 
> > At this point it is too late. Flipping keywords would cause downgrades.
> > Let's hope that there are no failures.
> > 
> > Please proceed with cleanup.
> 
> There haven't been any reports since I've introduced the bumps. I may have
> gotten lucky this time.
> 
> I have figured out how to get repoman to run as a pre-commit hook, now. So,
> it's unlikely to happen again.

No worries, it happens. By the time I noticed, it was too late to revert lest some havoc be caused.

Besides, I appreciate you filing the bugs with full details, which more than makes up for it ;)

[Comment 10 GLSAMaker/CVETool Bot 2020-12-07 00:39:30 UTC]

This issue was resolved and addressed in
 GLSA 202012-07 at https://security.gentoo.org/glsa/202012-07
by GLSA coordinator Thomas Deutschmann (whissi).