Le PostgreSQL Global Development Group a publié une mise à jour de toutes les versions prises en charge de PostgreSQL, notamment 15.3, 14.8, 13.11, 12.15 et 11.20. Cette version corrige deux vulnérabilités de sécurité Pour la liste complète des modifications, veuillez consulter les notes de version.

Pour mémoire, PostgreSQL 11 cessera de recevoir des correctifs le 9 novembre 2023. Si vous exécutez PostgreSQL 11 dans un environnement de production, le PostgreSQL Global Development Group vous suggère de planifier une mise à niveau vers une version plus récente et prise en charge de PostgreSQL.

Les problèmes de sécurité corrigés

CVE-2023-2454 : CREATE SCHEMA ... schema_element annule les changements de protection search_path.

Versions concernées : 11 - 15. L'équipe de sécurité ne teste généralement pas les versions non prises en charge, mais précise ce problème est assez ancien et qu'il peut donc concerner des versions antérieures.

Cette vulnérabilité permet à un attaquant disposant du privilège CREATE au niveau de la base de données d'exécuter du code arbitraire en tant que superutilisateur d'amorçage. Les propriétaires de bases de données ont ce droit par défaut, et des octrois explicites peuvent l'étendre à d'autres utilisateurs.

Le projet PostgreSQL remercie Alexander Lakhin d'avoir signalé ce problème.

CVE-2023-2455 : les politiques de sécurité des lignes ne tiennent pas compte des modifications de l'ID utilisateur après l'intégration.

Versions concernées : 11 - 15. L'équipe de sécurité ne teste généralement pas les versions non prises en charge, mais précise ce problème est assez ancien et qu'il peut donc concerner des versions antérieures.

Bien que CVE-2016-2193 corrige la plupart des interactions entre la sécurité des lignes et les changements d'ID utilisateur, il a manqué un scénario impliquant l'intégration de fonctions. Cela conduit à l'application de stratégies potentiellement incorrectes dans les cas où des stratégies spécifiques à un rôle sont utilisées et qu'une requête donnée est planifiée sous un rôle, puis exécutée sous d'autres rôles. Ce scénario peut se produire sous les fonctions de définition de la sécurité ou lorsqu'un utilisateur et une requête communs sont initialement planifiés, puis réutilisés sur plusieurs SET ROLE. L'application d'une stratégie incorrecte peut permettre à un utilisateur d'effectuer des lectures et des modifications autrement interdites. Cela affecte uniquement les bases de données qui ont utilisé CREATE POLICY pour définir une politique de sécurité de ligne.