From upstream advisory: Supported, Vulnerable Versions: 9.3 - 10. The security team typically does not test unsupported versions, but this problem is quite old. The PostgreSQL search_path setting determines schemas searched for tables, functions, operators, etc. The pg_dump client application chooses search_path settings such that every schema may appear at the front of its search path. This permits a user with CREATE privilege on any schema to execute arbitrary SQL functions under the identity of the user running pg_dump, often a superuser. This is exploitable in the default configuration, where all users have CREATE privilege on schema "public". The pg_upgrade implementation invokes pg_dump under a superuser identity, and its usage is vulnerable. Other client applications, such as vacuumdb, leave search_path unchanged. In the default configuration, users can create objects in the "public" schema and harness them to execute arbitrary SQL functions under the identity of the user running these programs. The PostgreSQL project estimates this class of vulnerability is pervasive in applications that query PostgreSQL databases, so we are issuing guidance for database administrators and application authors to secure their own work. In brief, one can issue "REVOKE CREATE ON SCHEMA public FROM PUBLIC" to prevent these attacks.
Both RHMAP services unified-push-server, and millicore don't use a Postgres database. Marking them as not affected.
JON does not include a Postgres database, but does use one. Upgrading the database to 9.5.12 to pick up a fix for this issue would be a good idea for JON users, and will not break compatibility. https://access.redhat.com/documentation/en-us/red_hat_jboss_operations_network/3.3/html/installation_guide/setting-up-dbs
External References: https://www.postgresql.org/about/news/1834/
Created mingw-postgresql tracking bugs for this issue: Affects: epel-7 [bug 1550902] Affects: fedora-all [bug 1550903] Created postgresql tracking bugs for this issue: Affects: fedora-all [bug 1550901]
Mitigation: Upstream suggests the following mitigation can be used to protect against this security flaw: https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path
Statement: This issue affects the versions of Postgresql as shipped with Red Hat Satellite 5. Red Hat Product Security has rated this issue as having security impact of Low. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS Via RHSA-2018:2511 https://access.redhat.com/errata/RHSA-2018:2511
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS Via RHSA-2018:2566 https://access.redhat.com/errata/RHSA-2018:2566
This issue has been addressed in the following products: CloudForms Management Engine 5.9 Via RHSA-2018:3816 https://access.redhat.com/errata/RHSA-2018:3816
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,