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".
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]
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.
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.
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
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.