LOXODATA

PostgreSQL 9.6.4 et autres correctifs

2017-08-10   1312 mots, 7 minutes de lecture

Mise à jour de sécurité du 10 août 2017

Le PostgreSQL Global Development Group publie une mise à jour de toutes les versions supportées. Ces mises à jour incluent les versions 9.6.4, 9.5.8, 9.4.13, 9.3.18 et 9.2.22.

Ces nouvelles versions corrigent trois failles de sécurité. Elles intègrent aussi la correction de plus de 50 autres bugs rapportés ces 3 derniers mois.

Les utilisateurs qui rencontrent les failles de sécurité listées ci-dessous doivent mettre à jour leur système le plus tôt possible. Les utilisateurs affectés par CVE-2017-7547 devront effectuer des étapes supplémentaires à la fin de la mise à jour pour corriger le problème. Pour les autres utilisateurs, nous conseillons de planifier la mise à jour lors de la prochaine maintenance préventive.

Failles de sécurité

Trois vulnérabilités ont été corrigées dans cette mise à jour:

  • CVE-2017-7546: Mot de passe vide accepté pour certaines méthodes d’authentification
  • CVE-2017-7547: La vue “pg_user_mappings” divulgue les mots de passe aux utilisateurs non autorisés
  • CVE-2017-7548: la fonction lo_put() ignore les ACLs

CVE-2017-7546: Mot de passe vide accepté pour certaines méthodes d’authentification

libpq (et par extension tout pilote de connexion qui utilise libpq) ignore les mots de passe vides et ne les transmet pas à l’instance. Quand on utilise libpq ou un pilote de connexion basé sur libpq pour une authentification par mot de passe, définir un mot de passe vide est équivalent à désactiver la connexion par mot de passe. Cependant, l’utilisation d’un pilote de connexion non basé sur libpq peut permettre à un client avec un mot de passe vide de se connecter à une instance.

Pour corriger le problème, cette mise à jour désactive les mots de passe vides pour toute méthode d’authentification basée sur les mots de passe. L’instance rejettera toute tentative d’utilisation d’un mot de passe vide sur les comptes utilisateur.

CVE-2017-7547: La vue “pg_user_mappings” divulgue les mots de passe aux utilisateurs non autorisés

Le soucis concerne le mapping entre les utilisateurs du serveur local et les utilisateurs distants lors de l’utilisation des Foreign Data Wrapper.

Avant ce correctif, un utilisateur pouvait accéder à la vue pg_user_mappings, même si celui-ci n’avait pas les droits d’USAGE sur l’instance distante. Cela signifie qu’un utilisateur pouvait voir des informations comme les mots de passe (s’ils avaient été créés par l’administrateur de l’instance plutôt que par l’utilisateur lui-même).

Ce correctif ne sera actif que pour les nouveaux groupes de bases de données créés avec initdb.

Pour corriger ce problème sur des systèmes existants, il faut effectuer les étapes suivantes. Pour plus d’informations, merci de regarder les release notes.

  1. Dans le fichier postgresql.conf, ajouter le paramètre suivant:
allow_system_table_mods = true
  1. Après avoir ajouté cette ligne, redémarrer l’instance PostgreSQL.

  2. Dans chaque base de données de l’instance, exécuter les commandes suivantes (en tant que 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);
  1. Cette commande doit également être jouée sur les bases template0 et template1, sans quoi la vulnérabilité continuera d’exister dans les futures bases de données créées. Il faut tout d’abord autoriser l’accès pour template0. Pour PostgreSQL 9.5 :
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;

Pour PostgreSQL 9.4 et inférieur :

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

Ensuite, dans les bases de données template0 et template1, exécuter les commandes de l'étape 3. Puis, désactiver les connexions sur template0. Pour PostgreSQL 9.5 :

ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;

Pour PostgreSQL 9.4 et inférieur :

UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
  1. Supprimer du fichier postgresql.conf la ligne :
allow_system_table_mods = false
  1. Redémarrer l’instance postgreSQL

Pour plus d’information, voir les release notes.

CVE-2017-7548: la fonction lo_put() ignore les ACLs

La fonction lo_put() devrait nécessiter les mêmes permissions que lowrite(), mais il manquait une vérification qui permettait à n’importe quel utilisateur de changer les données d’un large object.

Pour corriger ce problème, la fonction lo_put() a été changée pour vérifier les droits d’UPDATE sur l’objet cible.

Corrections de bugs et améliorations

Cette mise à jour corrige aussi un certain nombre de bugs rapportés ces derniers mois. Certains ne concernent que la version 9.6, mais la plupart concernent toutes les version supportées.

  • pg_upgrade: la documentation décrivant la procédure de mise à jour d’instances secondaires,en conservant une synchronisation correcte entre nœud primaire et secondaire, a été corrigée. Une note a été ajoutée pour enjoindre l’utilisateur à vérifier que le paramètre wal_level est différent de minimal, ce qui empêcherait la reconnexion des secondaires au redémarrage.
  • Correction du problème d’accès concurrents qui pouvait faire échouer un UPDATE
  • Plusieurs solutions permettant d’empêcher des scenarios (peu probables) de corruption de données
  • Un correctif pour empêcher un crash de l’instance lors des tris de plus d’un milliard de lignes en mémoire
  • Un correctif, pour la version Windows, permettant d’essayer de créer un nouveau processus au cas où les adresses de la mémoire partagée ne seraient plus allouées, cas typique d’intéraction avec un logiciel antivirus
  • un correctif de libpq pour assurer que les tentatives de connexions en erreur utilisant les authentifications GSS/SASL et SSPI soit correctement fermées
  • Un correctif de gestion des connexions SSL, et de gestion de leurs traces
  • Un correctif pour permettre aux fonctions de fenêtrage d'être utilisées dans une sous-requête utilisée comme argument d’une fonction d’aggrégation
  • Permettre le parallélisme d’un plan d’exécution quand COPY est utilisé à partir d’une requêtre SQL
  • Plusieurs correctifs sur ALTER TABLE
  • Un correctif pour que les ordres SQL ALTER USER ... SET et ALTER ROLE ... SET acceptent les mêmes syntaxes
  • Des correctifs sur le collecteur de statistiques permettant que les collectes de statistiques effectuées juste après une demande d’arrêt de l’instance soient écrites sur disque
  • Correction de la possible création d’un fichier WAL invalide lors de la promotion d’un nœud secondaire
  • Plusieurs correctifs concernant les processus walsender et walreceiver, notamment sur le traitement des signaux et sur les arrêts/redémarrages
  • Plusieurs correctifs sur le décodage logique des WAL, y compris la suppression de fuites disques sur les petites sous-transactions
  • Permettre à une contrainte de type CHECK d'être dans l'état NOT VALID lors de l’exécution d’un ordre CREATE FOREIGN TABLE
  • Des correctifs de postgres_fdw pour appliquer les changements rapidement après un ordre ALTER SERVER ou ALTER USER MAPPING et pour améliorer la gestion des serveurs/instances qui ne répondent pas
  • Plusieurs correctifs de pg_dump et pg_restore, y compris un correctif de pg_dump lors de l’utilisation de la sortie standard sous Windows
  • Corrige la sortie standard de pg_basebackup sous Windows, similaire au correctif de pg_dump
  • Corrige pg_rewind pour lui permettre de gérer correctement des fichiers de plus de 2Go, même s’il est rare de trouver des fichiers de cette taille dans un répertoire de données
  • Plusieurs correctifs pour pouvoir compiler PostgreSQL avec Microsoft Visual C (MSVC)

Avertissement de fin de vie de vie pour la version 9.2

PostgreSQL version 9.2 arrive en fin de vie en septembre 2017. Cette version fera l’objet d’une dernière mise-à-jour. Nous conseillons très fortement aux utilisateurs de cette version de planifier une montée de version le plus vite possible. Voir notre politique de versionnement pour plus d’informations.

Mise à jour

Toutes les mises à jour de PostgreSQL sont cumulatives. Comme pour les autres versions mineures, il n’est pas nécessaire d’extraire et recharger les bases ou d’utiliser pg_upgrade pour appliquer cette mise à jour. Il suffit d’arrêter PostgreSQL, et de mettre à jour les binaires.

Pour les détails, on peut se référer aux notes de versions.

Liens