Bug 1645937 (CVE-2018-16850) - CVE-2018-16850 postgresql: SQL injection in pg_upgrade and pg_dump, via CREATE TRIGGER ... REFERENCING
Summary: CVE-2018-16850 postgresql: SQL injection in pg_upgrade and pg_dump, via CREAT...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2018-16850
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1649236 1649237 1649238 1649239 1649240 1649369 1649370
Blocks: 1645938
TreeView+ depends on / blocked
 
Reported: 2018-11-05 01:33 UTC by Sam Fowler
Modified: 2021-02-16 22:49 UTC (History)
50 users (show)

Fixed In Version: postgresql 11.1, postgresql 10.6
Doc Type: If docs needed, set a value
Doc Text:
A SQL Injection flaw has been discovered in PostgreSQL server in the way triggers that enable transition relations are dumped. The transition relation name is not correctly quoted and it may allow an attacker with CREATE privilege on some non-temporary schema or TRIGGER privilege on some table to create a malicious trigger that, when dumped and restored, would result in additional SQL statements being executed.
Clone Of:
Environment:
Last Closed: 2018-12-03 09:41:48 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3757 0 None None None 2018-12-03 08:25:30 UTC

Description Sam Fowler 2018-11-05 01:33:19 UTC
Postgresql before versions 11.1 and 10.6 are vulnerable to SQL injection in pg_upgrade and pg_dump via CREATE TRIGGER ... REFERENCING. Using a purpose-crafted trigger definition, an attacker can cause arbitrary SQL statements to run, with superuser privileges, during the next pg_upgrade of the database or the next pg_dump dump/restore cycle. The attack requires CREATE privilege on some non-temporary schema or TRIGGER privilege on some table. This is exploitable in the default configuration, where all users have CREATE privilege on schema "public".

Comment 2 Andrej Nemec 2018-11-13 08:36:39 UTC
External References:

https://www.postgresql.org/about/news/1905/

Comment 3 Andrej Nemec 2018-11-13 08:37:34 UTC
Created mingw-postgresql tracking bugs for this issue:

Affects: epel-7 [bug 1649238]
Affects: fedora-all [bug 1649237]


Created postgresql tracking bugs for this issue:

Affects: fedora-all [bug 1649236]

Comment 8 Riccardo Schirone 2018-11-13 13:41:07 UTC
Since postgresql version 10, when creating a trigger you can specify a name to enable transition relations. This name, however, is not properly quoted when dumping the database, allowing to inject SQL code in the dump, which is later run by a superuser to restore the database.

Comment 9 Riccardo Schirone 2018-11-13 13:48:38 UTC
As said in comment 0, the attack requires CREATE privilege on some non-temporary schema or TRIGGER privilege on some table. However, a new user with no special permissions have by default CREATE permissions on the "public" schema, which would allow him to exploit the flaw.

Comment 16 errata-xmlrpc 2018-12-03 08:25:11 UTC
This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS

Via RHSA-2018:3757 https://access.redhat.com/errata/RHSA-2018:3757

Comment 17 Cedric Buissart 2018-12-03 13:26:08 UTC
Statement:

This issue did not affect the versions of postgresql as shipped with Red Hat Enterprise Linux 5, 6, and 7 as they did not include support for triggers with `referecing` syntax, which was included in a later version of the program. 

It also doesn't affect the versions of postgresql shipped with CloudForms 4.2, 4.5 and 4.6,  and Satellite 5, for the same reason as above.

This issue did not affect the versions of postgresql shipped within Tower, as there is no code path for Tower users to call the CREATE statement.

Comment 18 Trupti Pardeshi 2019-10-31 09:04:16 UTC
Hello,

May I know if Linux PostgreSQL 7.1beta6 version is also affected and requires this fix? Any heads up will be appreciated.

Thank you in advance.

Best Regards,


Note You need to log in before you can comment on or make changes to this bug.