Release_Notes_9_1_24LTS2

Release Notes for 9.1.24lts2

Release Date: 2017-08-10

This release contains a variety of fixes from 9.1.24lts1, adopted from the 9.2.22
release. For information about new features in the 9.1 major release, see
the 9.1 release notes.

The PostgreSQL community has stopped releasing updates for the 9.1.X release
series in October 2016. This update is a Long-Term-Support (LTS) community
effort by credativ GmbH and not an official release by the PostgreSQL community.

Migration to Version 9.1.24lts2

A dump/restore is not required for those running 9.1.X.

However, if you use foreign data servers that make use of user passwords for
authentication, see the first changelog entry below.

Also, if you are upgrading from a version earlier than 9.1.16, see the relevant
release notes.

Changes

• Further restrict visibility of pg_user_mappings.umoptions, to
  protect passwords stored as user mapping options (Noah Misch)

  The fix for CVE-2017-7486 was incorrect: it allowed a user to see the
  options in her own user mapping, even if she did not have USAGE permission
  on the associated foreign server. Such options might include a password
  that had been provided by the server owner rather than the user herself.
  Since information_schema.user_mapping_options does not show the options in
  such cases, pg_user_mappings should not either. (CVE-2017-7547)

  By itself, this patch will only fix the behavior in newly initdb'd databases.
  If you wish to apply this change in an existing database, you will need to do
  the following:

  • Restart the postmaster after adding allow_system_table_mods = true to
    postgresql.conf. (In versions supporting ALTER SYSTEM, you can use that
    to make the configuration change, but you'll still need a restart.)

  • In each database of the cluster, run the following commands as
    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);

• • Do not forget to include the template0 and template1 databases, or the
    vulnerability will still exist in databases you create later. To fix
    template0, you'll need to temporarily make it accept connections.
    In PostgreSQL 9.5 and later, you can use

ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;

and then after fixing template0, undo that with

ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;

In prior versions, instead use

UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

• • Finally, remove the allow_system_table_mods configuration
    setting, and again restart the postmaster.

• Disallow empty passwords in all password-based authentication methods
  (Heikki Linnakangas)

  libpq ignores empty password specifications, and does not transmit them to
  the server. So, if a user's password has been set to the empty string, it's
  impossible to log in with that password via psql or other
  libpq-based clients. An administrator might therefore believe that
  setting the password to empty is equivalent to disabling password login.
  However, with a modified or non-libpq-based client, logging in could be
  possible, depending on which authentication method is configured. In
  particular the most common method, md5, accepted empty passwords.
  Change the server to reject empty passwords in all cases. (CVE-2017-7546)