rh-postgresql10-postgresql-10.5-1.el7

PostgreSQL is an advanced object-relational database management system (DBMS).

The following packages have been upgraded to a later upstream version: rh-postgresql10-postgresql (10.5). (BZ#1612673, BZ#1614337)

Security Fix(es):

* postgresql: Certain host connection parameters defeat client-side security defenses (CVE-2018-10915)

* postgresql: Missing authorization and memory disclosure in INSERT ... ON CONFLICT DO UPDATE statements (CVE-2018-10925)

* postgresql: Too-permissive access control list on function pg_logfile_rotate() (CVE-2018-1115)

For more details about the security issue(s), including the impact, a CVSS score, and other related information, refer to the CVE page(s) listed in the References section.

Asianux would like to thank the PostgreSQL project for reporting these issues. Upstream acknowledges Andrew Krasichkov as the original reporter of CVE-2018-10915; and Stephen Frost as the original reporter of CVE-2018-1115.

CVE-2018-1115
postgresql before versions 10.4, 9.6.9 is vulnerable in the adminpack extension, the pg_catalog.pg_logfile_rotate() function doesn't follow the same ACLs than pg_rorate_logfile. If the adminpack is added to a database, an attacker able to connect to it could exploit this to force log rotation.
CVE-2018-10915
A vulnerability was found in libpq, the default PostgreSQL client library where libpq failed to properly reset its internal state between connections. If an affected version of libpq was used with "host" or "hostaddr" connection parameters from untrusted input, attackers could bypass client-side connection security features, obtain access to higher privileged connections or potentially cause other impact through SQL injection, by causing the PQescape() functions to malfunction. Postgresql versions before 10.5, 9.6.10, 9.5.14, 9.4.19, and 9.3.24 are affected.
CVE-2018-10925
It was discovered that PostgreSQL versions before 10.5, 9.6.10, 9.5.14, 9.4.19, and 9.3.24 failed to properly check authorization on certain statements involved with "INSERT ... ON CONFLICT DO UPDATE". An attacker with "CREATE TABLE" privileges could exploit this to read arbitrary bytes server memory. If the attacker also had certain "INSERT" and limited "UPDATE" privileges to a particular table, they could exploit this to update other columns in the same table.