2017-08-10 Security Update Release
==================================
-The PostgreSQL Global Development Group has released an update to all supported versions of our database system, including 9.6.4, 9.5.8, 9.4.13, 9.3.18, and 9.2.22. This release fixes {{ NUMBER }} security issues. It also patches over 50 other bugs reported over the last three months. Users who {{ AFFECTED SECURITY CONDITION }} should update as soon as possible. Other users should plan to update at the next convenient downtime.
+The PostgreSQL Global Development Group has released an update to all supported versions of our database system, including 9.6.4, 9.5.8, 9.4.13, 9.3.18, and 9.2.22. This release fixes three security issues. It also patches over 50 other bugs reported over the last three months. Users who are affected by the below security issues should update as soon as possible. Users affected by [CVE-2017-7547](https://access.redhat.com/security/cve/CVE-2017-7547) will need to perform additional steps after upgrading to resolve the issue. Other users should plan to update at the next convenient downtime.
Security Issues
---------------
-{{ NUMBER }} security vulnerabilities have been closed by this release:
+Three security vulnerabilities have been closed by this release:
-* [CVE-0000-0000](https://access.redhat.com/security/cve/CVE-0000-0000): {{ CVE_SUMMARY }}
+* [CVE-2017-7546](https://access.redhat.com/security/cve/CVE-2017-7546): Empty password accepted in some authentication methods
+* [CVE-2017-7547](https://access.redhat.com/security/cve/CVE-2017-7547): The "pg_user_mappings" catalog view discloses passwords to users lacking server privileges
+* [CVE-2017-7548](https://access.redhat.com/security/cve/CVE-2017-7548): lo_put() function ignores ACLs
-{{ EXTRA NOTES ON ISSUES AND BACKWARDS COMPATIBILITY }}
+CVE-2017-7546: Empty password accepted in some authentication methods
+--------------------------
+
+libpq, and by extension any connection driver that utilizes libpq, ignores empty passwords and does not transmit them to the server. When using libpq or a libpq-based connection driver to perform password-based authentication methods, it would appear that setting an empty password would be the equivalent of disabling password login. However, using a non-libpq based connection driver could allow a client with an empty password to log in.
+
+To fix this issue, this update disables empty passwords from being submitted in any of the password-based authentication methods. The server will reject any empty passwords from being set on accounts.
+
+CVE-2017-7547: The "pg_user_mappings" catalog view discloses passwords to users lacking server privileges
+--------------------------
+
+This fix pertains to the usage of the foreign data wrapper functionality, particularly for the user mapping feature.
+
+Before this fix, a user had access to see the options in pg_user_mappings even if the user did not have the USAGE permission on the associated foreign server. This meant that a user could see details such as a password that might have been set by the server administrator rather than the user.
+
+This fix will only fix the behavior in newly created clusters utilizing initdb. To fix this issue on existing systems, you will need to follow the below steps. For more details, please see the [release notes](https://www.postgresql.org/docs/current/static/release-9-6-4.html).
+
+1. In your postgresql.conf file, add the following:
+
+ allow_system_table_mods = true
+
+2. After adding that line, you will need to restart your PostgreSQL cluster.
+
+3. In **each** database of the cluster, run the following commands as a superuser:
+
+ SET search_path = pg_catalog;
+ CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user
+ AND (pg_has_role(S.srvowner, 'USAGE')
+ OR has_server_privilege(S.oid, 'USAGE')))
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser)
+ JOIN pg_foreign_server S ON (U.umserver = S.oid);
+
+4. You also need to run the command on your *template0* and *template1* databases, otherwise the vulnerability will exist in future databases that you create.
+
+First, you will need to allow *template0* to accept connections. In PostgreSQL 9.5 you can run the following:
+
+ ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+
+In PostgreSQL 9.4 and below, you will have to run this command:
+
+ UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+
+Then, in your *template0* and *template1* databases, run the commands as describe in Step 3
+
+When you are done, you will need to disallow connections from *template0*. In PostgreSQL 9.5, you can run the following:
+
+ ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+
+In PostgreSQL 9.4 and below, you will have to run the following:
+
+ UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+
+5. Remove the following line from your postgresql.conf file:
+
+ allow_system_table_mods = false
+
+6. Restart your PostgreSQL cluster
+
+For more details, please see the [release notes](https://www.postgresql.org/docs/current/static/release-9-6-4.html).
+
+CVE-2017-7548: lo_put() function ignores ACLs
+--------------------------
+
+The lo_put() function should require the same permissions as lowwrite(), but there was a missing permission check which would allow any user to change the data in a large object.
+
+To fix this, the lo_put() function was changed to check the UPDATE privileges on the target object.
Bug Fixes and Improvements
--------------------------
projects / press.git / commitdiff