Sortie de PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17 et 12.21

Publié le 15/11/2024 par Alain Lesage, David Bidoc, Laura Ricci

Paris, le 15 novembre 2024

Le PostgreSQL Global Development Group a publié une mise à jour pour toutes les versions supportées de PostgreSQL, c’est à dire les versions 17.1, 16.5, 15.9, 14.14, 13.17 et 12.21. Cette version corrige quatre failles de sécurité et plus de 35 bugs signalés au cours des derniers mois. Voici notre traduction.

visuel annonce

Note importante (18 novembre 2024)

Depuis la sortie de ces versions mineures, deux importantes régressions ont été découvertes. Il est fortement conseillé de ne pas mettre à jour ! De nouvelles versions mineures sortiront jeudi 21 novembre. Quelques détails sont disponibles sur ce message de Jonathan Katz.

Note sur la fin de vie de PostgreSQL 12

Il s’agit de la dernière version de PostgreSQL 12. PostgreSQL 12 est maintenant obsolète et ne recevra plus de correctifs de sécurité et de bogues. Si vous utilisez PostgreSQL 12 dans un environnement de production, nous vous suggérons de planifier une mise à jour vers une version plus récente et supportée de PostgreSQL. Veuillez consulter la politique de versionnement pour plus d’informations.

Failles de sécurité

CVE-2024-10976

La sécurité des lignes dans PostgreSQL, par exemple dans les sous-requêtes, ignore les changements de l’ID utilisateur.

Score CVSS v3.1 : 4.2

Versions supportées vulnérables : PostgreSQL 12 à 17

Un suivi incomplet dans PostgreSQL des tables avec politiques de sécurité niveau ligne permet à une requête réutilisée de voir ou de modifier des lignes différentes de celles prévues. CVE-2023-2455 et CVE-2016-2193 ont corrigé la plupart des interactions entre la sécurité des lignes et les changements d’ID utilisateur. Ils ont omis les cas où une sous-requête, une requête WITH, une vue d’invocateur de sécurité ou une fonction du langage SQL fait référence à une table avec politiques de sécurité niveau ligne. Cela a les mêmes conséquences que les deux CVE précédents. En d’autres termes, cela conduit à l’application de politiques potentiellement incorrectes dans les cas où des politiques spécifiques à un rôle sont utilisées et où une requête donnée est planifiée sous un rôle et ensuite exécutée sous d’autres rôles. Ce scénario peut se produire dans le cadre de fonctions de définition de la sécurité ou lorsqu’un utilisateur et une requête communs sont planifiés initialement, puis réutilisés dans le cadre de plusieurs rôles (SET ROLE).

L’application d’une politique incorrecte peut permettre à un utilisateur d’effectuer des lectures et des modifications autrement interdites. Ceci n’affecte que les bases de données qui ont utilisé CREATE POLICY pour définir des politiques de sécurité niveau ligne. Un attaquant doit adapter son attaque au modèle de réutilisation du plan de requête d’une application particulière, aux changements d’identifiant de l’utilisateur, et aux politiques de sécurité des lignes spécifiques à chaque rôle. Les versions antérieures à PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, et 12.21 sont concernées.

Le projet PostgreSQL remercie Wolfgang Walther pour avoir signalé ce problème.

CVE-2024-10977

La bibliothèque libpq conserve un message d’erreur provenant d’une attaque de type “man in the middle”.

Score CVSS v3.1 : 3.1

Versions supportées vulnérables : PostgreSQL 12 à 17

L’utilisation par le client des messages d’erreur du serveur dans PostgreSQL permet à un serveur non approuvé (selon les paramètres SSL ou GSS actuels) de transmettre des octets arbitraires sans caractère NULL à l’application utilisant libpq. Par exemple, un attaquant de type “man in the middle” pourrait envoyer un long message d’erreur, que l’utilisateur ou un analyseur de sortie de psql pourrait interpréter à tort comme des résultats de requête valides. Cela ne devrait probablement pas poser de problème pour les clients dont l’interface utilisateur indique clairement la différence entre un message d’erreur et le reste du texte. Les versions antérieures à PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, et 12.21 sont concernées.

Le projet PostgreSQL remercie Jacob Champion pour avoir signalé ce problème.

CVE-2024-10978

Les commandes SET ROLE et SET SESSION AUTHORIZATION se réinitialisent à un mauvais ID utilisateur.

Score CVSS v3.1 : 4.2

Versions supportées vulnérables : PostgreSQL 12 à 17

Une mauvaise attribution de privilèges dans PostgreSQL permet à un utilisateur d’application moins privilégié de visualiser ou de modifier des lignes différentes de celles prévues. L’attaque nécessite pour l’application d’utiliser SET ROLE, SET SESSION AUTHORIZATION, ou une fonctionnalité équivalente. Le problème survient quand une requête applicative utilise des paramètres de l’attaquant ou transmet les résultats d’une requête à l’attaquant. Si cette requête réagit à current_setting(‘role’) ou à l’ID utilisateur courant, elle peut modifier ou renvoyer des données comme si la session n’avait pas utilisé SET ROLE ou SET SESSION AUTHORIZATION. L’attaquant ne contrôle pas quel ID utilisateur incorrect s’applique. Les requêtes provenant de sources moins privilégiées ne posent pas problème ici, car SET ROLE et SET SESSION AUTHORIZATION ne sont pas des bacs à sable pour les requêtes non vérifiées. Les versions antérieures à PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, et 12.21 sont concernées.

Le projet PostgreSQL remercie Tom Lane pour avoir signalé ce problème.

CVE-2024-10979

La modification de variables d’environnement PL/Perl permet l’exécution de code arbitraire.

Score CVSS v3.1 : 8.8

Versions supportées vulnérables : PostgreSQL 12 à 17

Un contrôle incorrect des variables d’environnement dans PostgreSQL PL/Perl permet à un utilisateur de base de données non privilégié de modifier des variables d’environnement de processus sensibles (par exemple PATH). Cela suffit souvent à permettre l’exécution de code arbitraire, même si l’attaquant ne dispose pas d’un utilisateur sur le système d’exploitation du serveur de base de données. Les versions antérieures à PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17 et 12.21 sont concernées.

Le projet PostgreSQL remercie Coby Abrams pour avoir signalé ce problème.

Correctifs et améliorations

Cette mise à jour corrige 35 problèmes rapportés ces derniers mois. Ceux ci-dessous concernent PostgreSQL 17. Certains peuvent affecter d’autres versions supportées.

  • Correction concernant l’attachement ou le détachement d’une partition de table comportant une contrainte de clé étrangère. Après mise à jour, les utilisateurs concernés par ce problème devront effectuer des opération manuelles pour finir la correction. Merci de consulter la partie “Mise à jour” et la note de version pour plus d’information.
  • Correction quand la libc est utilisée comme source de collation quand LC_CTYPE est C alors que LC_COLLATE est à une différente locale. Ceci pouvait entraîner des résultats de requêtes incorrects. Si vous avez ces paramètres dans votre instance, veuillez réindexer tous les index concernés après mise à jour de cette version. Ce problème concerne la version 17.0 seulement.
  • Plusieurs corrections sur le planificateur de requêtes, incluant l’interdiction de jointure de partition (partitionwise join) si les collations entre les partitions ne correspondent pas.
  • Corrige des possibles mauvaises réponses ou erreurs wrong varnullingrels du planificateur pour la commande MERGE ... WHEN NOT MATCHED BY SOURCE.
  • Corrige la validation de COPY FORCE_NOT_NULL et FORCE_NULL.
  • Corrige un crash de l’instance quand un appel json_objectagg() contient une fonction volatile.
  • Assure qu’il y ait une dépendance enregistrée entre une table partitionnée et une méthode d’accès tierce spécifiée dans CREATE TABLE ... USING. Ceci ne corrige le problème que pour les tables partitionnées crées après cette mise à jour.
  • Corrige la condition de concurrence dans la validation d’une transaction sérialisable.
  • Corrige la condition de concurrence dans COMMIT PREPARED qui pouvait nécessiter une suppression de fichier manuelle après un crash et une récupération.
  • Correction de la vue pg_cursors pour éviter les erreurs en excluant les curseurs qui ne sont pas complètement configurés.
  • Réduction de la consommation de mémoire du décodage logique.
  • Correction pour empêcher les fonctions stables de recevoir des valeurs de lignes obsolètes lorsqu’elles sont appelées depuis une liste d’arguments d’une instruction CALL et que le CALL est dans un bloc EXCEPTION PL/pgSQL.
  • Correction des plantages JIT sur les systèmes ARM (aarch64).
  • Le \watch de psql traite maintenant les valeurs qui sont inférieures à 1 ms comme 0 (pas d’attente entre les exécutions).
  • Correction de l’échec d’utilisation des identifiants pour un utilisateur de réplication dans le fichier de mot de passe (pgpass).
  • pg_combinebackup génère maintenant une erreur si un fichier de sauvegarde incrémentale est présent dans un répertoire qui devrait contenir une sauvegarde complète.
  • Correction pour éviter la réindexation des tables et index temporaires dans vacuumdb et reindexdb parallèle.

Cette mise à jour contient également les fichiers de fuseaux horaires tzdata en version 2024b. Cette version de tzdata change les anciens noms de zones compatibles avec System-V pour reproduire les zones géographiques correspondantes ; par exemple, PST8PDT est maintenant un alias pour America/Los_Angeles. La principale conséquence visible est que, pour les horodatages antérieurs à l’introduction de fuseaux horaires normalisés, le fuseau est considéré comme représentant le temps solaire moyen local pour le lieu indiqué. Par exemple, en PST8PDT, une entrée timestamptz telle que 1801-01-01 00:00 aurait auparavant été rendue par 1801-01-01 00:00:00-08, mais elle est maintenant rendue par 1801-01-01 00:00:00-07:52:58.

De plus, des corrections historiques pour le Mexique, la Mongolie et le Portugal. Notamment, Asia/Choibalsan est désormais un alias de Asia/Ulaanbaatar au lieu d’être une zone distincte, principalement parce qu’il s’est avéré que les différences entre ces zones étaient basées sur des données peu fiables.

Mise à jour

Toutes les mises à jour de PostgreSQL sont cumulatives. Comme pour les autres versions mineures, les utilisateurs n’ont pas besoin de sauvegarder et recharger leur base de données, ni d’utiliser pg_upgrade pour appliquer la mise à jour. Vous pouvez simplement arrêter PostgreSQL et mettre à jour ses binaires.

Si vous avez une table partitionnée avec des contraintes de clés étrangères où vous avez utilisé les commandes ATTACH PARTITION/DETACH PARTITION, vous devez effectuer des opérations supplémentaires après la mise à jour. Vous pouvez corriger ceci en lançant une commande ALTER TABLE ... DROP CONSTRAINT sur la désormais indépendante pour chaque contrainte défectueuse, puis ajouter de nouveau la contrainte. Si recréer la contrainte échoue, vous devrez manuellement rétablir la cohérence entre les tables de référence et les tables référencées, puis recréer la contrainte. Cette requête peut être utilisée pour identifier les contraintes défectueuses et construire les commandes nécessaires pour les recréer :

SELECT conrelid::pg_catalog.regclass AS "constrained table", 
       conname AS constraint, 
       confrelid::pg_catalog.regclass AS "references", 
       pg_catalog.format('ALTER TABLE %s DROP CONSTRAINT %I;', conrelid::pg_catalog.regclass, conname) AS "drop", 
       pg_catalog.format('ALTER TABLE %s ADD CONSTRAINT %I %s;', conrelid::pg_catalog.regclass, conname, pg_catalog.pg_get_constraintdef(oid)) AS "add" 
  FROM pg_catalog.pg_constraint c 
 WHERE contype = 'f' 
   AND conparentid = 0 
   AND (SELECT count(*) 
          FROM pg_catalog.pg_constraint c2  
         WHERE c2.conparentid = c.oid) <>  (
               SELECT count(*) 
                 FROM pg_catalog.pg_inherits i  
                WHERE (i.inhparent = c.conrelid OR i.inhparent = c.confrelid) 
                  AND EXISTS (SELECT 1 
                               FROM pg_catalog.pg_partitioned_table 
                              WHERE partrelid = i.inhparent
                      )
       );

Puisqu’il est possible qu’une ou plusieurs des étapes ADD CONSTRAINT échouent, vous devriez sauvegarder le résultat de cette requête dans un fichier et ensuite essayer de dérouler chaque étape.

De plus, si vous exécutez Postgresql 17.0 en utilisant libc comme source de collation par défaut, et avez défini LC_CTYPE à C alors que LC_COLLATE est dans une locale différente, vous devrez reconstruire vos index basés sur du texte. Vous pouvez le faire avec la commande REINDEX INDEX CONCURRENTLY.

Voir les notes de version pour les détails.

Liens

DALIBO

DALIBO est le spécialiste français de PostgreSQL®. Nous proposons du support, de la formation et du conseil depuis 2005.