PostgreSQL 17.2 et autres correctifs

2024-11-22

2094 mots, 10 minutes de lecture

Le PGDG (PostgreSQL Global Development Group) a publié une mise à jour de toutes les versions supportées de PostgreSQL, incluant 17.2, 16.6, 15.10, 14.15, 13.18.

PostgreSQL 12 est maintenant en fin de vie et ne devait plus recevoir de correctifs, mais étant donné la nature d’un problème présent dans la précédente publication, le PGDG (PostgreSQL Global Development Group) publie aussi la version 12.22 de PostgreSQL 12.

Les versions 17.1, 16.5, 15.9, 14.14, 13.17, et 12.21 publiées précédemment ne doivent pas être utilisées.

Cette publication corrige également 4 vulnérabilités de sécurités et plus de 35 bogues reportés dans les mois précédents.

Pour la liste complète des changements, se référer à la section Notes de publication.

Note : fin de vie de PostgreSQL 12

Il s’agit de la dernière publication de PostgreSQL 12. PostgreSQL 12 est maintenant en fin de vie et ne recevra plus de correctifs de sécurité ou de bogues. Si vous utilisez PostgreSQL 12 en production, nous vous suggérons de planifier une mise à jour vers une version plus récente et supportée de PostgreSQL. Se référer à notre politique de version pour plus d’informations.

Correctifs et améliorations de cette publication

Les problèmes ci-dessous concernent PostgreSQL 17. Certains de ces problèmes peuvent toutefois concerner d’autres versions de PostgreSQL.

Cette publication :

rétablit le fonctionnement de ALTER ROLE .. SET ROLE et ALTER DATABASE .. SET ROLE. Le correctif CVE-2024-10978 a accidentellement causé la non-application des rôles lorsqu’elle vient de sources non interactives, incluant les commandes ALTER {ROLE|DATABASE} et la variable d’environnement PGOPTIONS ;
rétablit la compatibilité de timescaledb et d’autres extensions compilées en utilisant une version de PostgreSQL précédent la publication du 14 novembre (17.0, 16.4, 15.8, 14.13, 13.16, 12.20, et précédents). Ce correctif rétablit la structure ResultRelInfo à sa taille précédente, ainsi les extensions affectées n’ont pas besoin d’être recompilées ;
corrige un cas où un slot de réplication logique pouvait revenir en arrière ;
annule la suppression de journaux de transactions (WAL) encore utiles pendant pg_rewind ;
corrige un problème d’exécution concurrente avec la suppression d’entrée de statistiques partagées, ce qui pouvait entrainer la perte de données statistiques ;
corrige une défaillance d’ALTER TABLE lors de la vérification du changement d’options de classe d’opérateurs d’un index, si la table dispose d’un index avec une classe d’opérateurs différente de celle par défaut.

Problèmes de sécurité

CVE-2024-10976 : Les sécurités au niveau ligne (RLS) de PostgreSQL dans une sous-requête ne tiennent pas compte des changements d’identifiant utilisateur.
- CVSS v3.1 Base Score: 4.2
- Supported, Vulnerable Versions: 12 - 17.
Une traçabilité incomplète des tables avec une sécurité niveau ligne (RLS) dans PostgreSQL permet à une requête réutilisée de modifier ou d’afficher des lignes différentes de celles prévues. Les CVE-2023-2455 et CVE-2016-2193 ont fixé la plupart des interactions avec une politique de sécurité au niveau ligne. Il s’agit des mêmes conséquences que ces 2 précédents CVE. En d’autres termes, cela conduit à l’application de politiques RLS potentiellement incorrectes dans les cas où des politiques RLS spécifiques à un rôle sont utilisées et où une requête donnée est planifiée dans le cadre d’un rôle, puis exécutée dans le cadre d’autres rôles. Ce scénario peut se produire dans le cadre des fonctions SECURITY DEFINER ou lorsqu’un utilisateur et une requête communs sont planifiés au départ, 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 qui ne seraient normalement pas autorisées. Ceci n’affecte que les bases de données qui ont utilisé CREATE POLICY pour définir une politique de sécurité des lignes (RLS). 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 aux rôles. Les versions antérieures à PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, et 12.21 sont affectées.

Le projet PostgreSQL remercie Wolfgang Walther pour avoir signalé ce problème.
CVE-2024-10977 : la bibliothèque libpq de PostgreSQL conserve un message d’erreur d’un composant « man-in-the-middle ».
- CVSS v3.1 Base Score: 3.1
- Supported, Vulnerable Versions: 12 - 17.
L’utilisation par une application cliente d’un message d’erreur de PostgreSQL permet à un serveur non fiable, selon les réglages SSL ou GSS courants, de fournir des octets arbitraires non-nuls à l’application utilisant la bibliothèque libpq. Par exemple, un attaquant MITM pourrait envoyer un long message d’erreur qu’un humain pourrait prendre par erreur pour le résultat d’une requête. Cela n’est probablement pas un problème pour les applications clientes pour lesquelles l’interface utilisateur indique de façon non ambigüe les limites d’un message d’erreur. Les versions antérieures à PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, et 12.21 sont affectées.

Le projet PostgreSQL remercie Jacob Champion pour avoir signalé ce problème.
CVE-2024-10978 : PostgreSQL SET ROLE, SET SESSION AUTHORIZATION est réinitialisé avec un mauvais identifiant.
- CVSS v3.1 Base Score: 4.2
- Supported, Vulnerable Versions: 12 - 17.
Une mauvaise affectation des privilèges dans PostgreSQL permet à un utilisateur applicatif non privilégié de voir ou de modifier des lignes différentes de celles prévues. Une attaque nécessite que l’application utilise SET ROLE, SET SESSION AUTHORIZATION, ou une fonctionnalité équivalente. Le problème survient lorsqu’une requête de l’application utilise des paramètres de l’attaquant ou transmet les résultats de la requête à l’attaquant. Si cette requête réagit à current_setting('role') ou à l’identifiant de l’utilisateur actuel, 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 identifiant incorrect s’applique. Le texte de la requête provenant de sources moins privilégiées n’est pas un problème ici, parce que 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 affectées.

Le projet PostgreSQL remercie Tom Lane pour avoir signalé ce problème.
CVE-2024-10979 : le changement d’une variable d’environnement de PL/Perl exécute arbitrairement du code.
- CVSS v3.1 Base Score: 8.8
- Supported, Vulnerable Versions: 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 sensibles (par exemple PATH). Ceci est souvent suffisant pour permettre l’exécution de code arbitraire, même si l’attaquant n’est pas un utilisateur du 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 affectées.

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

Corrections de bogues et améliorations

Cette mise à jour corrige plus de 35 bogues ayant été reportés durant les mois précédents. Les problèmes ci-dessous concernent PostgreSQL 17. Certains de ces problèmes peuvent aussi concerner d’autres versions de PostgreSQL.

Les correctifs sont :

correction de l’attachement ou du détachement d’une partition de table avec une contrainte de clé étrangère. Après la mise à jour, les utilisateurs impactés par ce problème devront exécuter des étapes manuelles pour terminer la correction. Merci de consulter la section Mise à jour de cette note de publication pour plus d’information ;
correction de l’utilisation de la libc comme collation par défaut lorsque LC_CTYPE est C alors qu’LC_COLLATE est une localisation différente. Ceci peut amener des résultats de requêtes incorrects. Si vous avez ces réglages dans votre base de données, il est nécessaire de réindexer les index impactés après la mise à jour. Ce problème ne concerne que PostgreSQL 17.0 ;
plusieurs corrections du Planner de requêtes, incluant l’interdiction de joindre des partitions (partitionwise join) si les collations des partitions ne correspondent pas ;
correction d’une potentielle mauvaise réponse ou mauvaise erreur du planner pour les actions MERGE ... WHEN NOT MATCHED BY SOURCE ;
corrections de la validation de COPY FORCE_NOT_NULL et FORCE_NULL ;
correction d’un crash du serveur quand un appel à la fonction json_objectagg() contient une fonction volatile ;
vérification qu’il y a une dépendance enregistrée entre une table partitionnée et une méthode d’accès non intégrée spécifiée dans CREATE TABLE ... USING. Ce correctif ne s’occupe que des tables partitionnées créées après cette mise à jour ;
correction d’un problème d’exécution concurrente lors de la validation d’une transaction sérialisable ;
correction d’un problème d’exécution concurrente dans un COMMIT PREPARED qui pourrait nécessiter la suppression manuelle d’un fichier après la récupération d’un crash ;
correction de la vue pg_cursors pour se prémunir d’erreur en excluant les curseurs lorsqu’ils ne sont pas complètement configurés ;
réduction de la consommation mémoire du décodage logique ;
correction pour empêcher les fonctions stables de recevoir des valeurs de lignes périmées lorsqu’elles sont appelées à partir de la liste d’arguments d’une instruction CALL et que le CALL se trouve dans un bloc d’EXCEPTION PL/pgSQL ;
correction d’un crash de JIT pour les systèmes ARM (aarch64) ;
la commande \watch de psql traite maintenant les valeurs inférieures à 1ms comme un 0 (pas d’attente entre les exécutions) ;
correction de l’impossibilité d’utiliser les informations d’identification d’un utilisateur de réplication dans le fichier de mots de passe (pgpass) ;
pg_combinebackup remonte 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 de réindexer les tables et index temporaires dans vacuumdb et parallel reindexdb.

Cette publication met aussi à jour les fichiers de fuseau horaire avec la publication de tzdata 2024b. Cette version de tzdata modifie les anciens noms de zones compatibles avec System-V pour dupliquer 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, la zone est considérée comme représentant le temps solaire moyen local pour l’emplacement nommé. Par exemple, dans 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.

Des corrections historiques ont également été apportées pour le Mexique, la Mongolie et le Portugal. Notamment, Asia/Choibalsan est maintenant un alias pour Asia/Ulaanbaatar au lieu d’être une zone séparée, principalement parce que les différences entre ces zones se sont avérées être basées sur des données peu fiables.

Mise à jour

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

Si vous utilisez des tables partitionnées avec des contraintes de clés étrangères pour lesquels vous avez fait des commandes ATTACH PARTITION/DETACH PARTITION, vous allez avoir besoin de faire quelques étapes après cette mise à jour. La correction s’obtient en exécutant une commande ALTER TABLE ... DROP CONSTRAINT sur la table désormais autonome pour chaque contrainte défectueuse, et en ajoutant à nouveau la contrainte. Si l’ajout de la contrainte échoue, vous devez alors rétablir manuellement la cohérence entre les tables référentes et référencées, puis créer à nouveau la contrainte.

Cette requête peut être utilisée pour identifier les contraintes défaillantes et construire les commandes 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));

Étant donné qu’il est possible qu’une ou plusieurs des étapes ADD CONSTRAINT échouent, vous devriez enregistrer la sortie de cette requête dans un fichier puis exécuter chaque étape.

De plus, si vous utilisez PostgreSQL 17.0 et libc comme fournisseur de collation par défaut, et que le paramètre LC_CTYPE vaut C alors que le paramètre LC_COLLATE a une valeur locale différente, vous allez avoir besoin de reconstruire les index basés sur du texte. Vous pouvez faire cela avec la commande REINDEX INDEX CONCURRENTLY.

Les utilisateurs ayant sauté une ou plusieurs mises à jour peuvent avoir besoin d’étapes additionnelles après la mise à jour. Les notes de publication des versions précédentes fournissent les détails.

Pour plus de détails, se référer à la note de publication de versions.

Liens

Si vous avez des corrections ou suggestions sur cette annonce de publication, merci de les envoyer à la mailing liste publique pgsql-www@lists.postgresql.org.