La limite « gérée » n'était pas un mur
Les fournisseurs de PostgreSQL géré comme Supabase, Neon et Amazon Aurora offrent aux clients des rôles administratifs puissants, mais leur refusent les véritables privilèges de superuser. Ils visent à fournir un environnement multi-tenant sécurisé où les utilisateurs contrôlent leur base de données sans impacter l'hôte sous-jacent ou les autres clients.
Les fournisseurs y parviennent en déployant des extensions ou des hooks personnalisés. Ces couches interceptent et bloquent les opérations potentiellement dangereuses, en particulier celles impliquant le système de fichiers, même pour les rôles clients les plus élevés. Par exemple, un fournisseur peut bloquer lo_export, une fonction native de PostgreSQL conçue pour écrire des objets volumineux sur le disque du serveur.
Cette couche de restriction personnalisée peut cependant créer un faux sentiment de sécurité. Si la barrière de sécurité ne vérifie que le nom d'une commande plutôt que sa fonctionnalité sous-jacente, un utilisateur peut contourner le blocage. Réenregistrer le même alias de fonction C interne sous un nouveau nom non surveillé permet de contourner la liste de blocage, autorisant l'invocation de fonctionnalités autrement restreintes.
Un nouveau nom est passé à travers le filtre
Le contournement signalé a exploité un angle mort critique dans le filtrage basé sur les noms. La fonction lo_export de PostgreSQL écrit les objets volumineux de la base de données directement sur les fichiers du serveur. Les fournisseurs gérés, conscients de ce danger, bloquent généralement lo_export par son nom, empêchant son exécution même pour les rôles clients puissants.
Un chercheur en sécurité a démontré comment contourner cette barrière. Il a recréé l'accès à la routine interne sous-jacente en utilisant le mécanisme LANGUAGE internal de PostgreSQL. Cela lui a permis de définir une nouvelle fonction avec un nom non surveillé qui pointait vers la même implémentation C backend que la fonction lo_export bloquée.
Cette technique a permis de cloner efficacement la capacité dangereuse sous une étiquette différente, contournant ainsi l'extension de sécurité du fournisseur. Une fois cette fonction aliasée disponible, le chercheur a pu écrire des fichiers arbitraires sur le disque du serveur de base de données.
Cette vulnérabilité met en évidence une faiblesse fondamentale des modèles de sécurité reposant uniquement sur le filtrage par nom. Des noms alternatifs peuvent pointer vers la même implémentation sous-jacente, ce qui signifie que vérifier uniquement l'étiquette ne revient pas à contrôler la capacité. Les extensions des fournisseurs bloquaient le mot « lo_export » mais pas l' action d'écrire des fichiers sur le serveur, laissant ainsi une faille de conception critique exposée.
De la permission SQL au code au niveau de l'hôte
La fonction lo_export répliquée, opérant désormais sous un alias non bloqué, a fourni une primitive critique : la capacité d'écrire des fichiers arbitraires sur l'hôte PostgreSQL. Les attaquants ont exploité cela pour déposer une bibliothèque partagée compilée (fichier .so) sur le disque du serveur.
Avec la bibliothèque malveillante en place, l'étape suivante consistait à l'enregistrer en tant que fonction en langage C de PostgreSQL. Cela est réalisé via CREATE FUNCTION ... LANGUAGE C, qui demande à PostgreSQL de charger et d'exposer une fonction spécifique de la bibliothèque partagée directement dans l'environnement SQL de la base de données.
Lorsqu'un attaquant invoquait ensuite cette fonction en langage C nouvellement enregistrée via une simple requête SQL, la base de données exécutait son code arbitraire. Il est crucial de noter que ce code s'exécutait avec les autorisations du système d'exploitation du processus PostgreSQL lui-même sur l'hôte de la base de données. Il ne s'agit pas d'un accès root, et cela n'accorde pas automatiquement l'accès aux données d'autres clients, car les instances sont généralement isolées.
Cependant, l'exécution sur l'hôte constitue un point d'ancrage significatif. Elle permet la persistance sur le serveur, autorise une énumération complète du système et peut faciliter les tentatives de mouvement latéral au sein de l'infrastructure du fournisseur. La gravité dépend fortement des mécanismes d'isolation spécifiques et des configurations réseau de chaque service géré. Pour une analyse technique détaillée, consultez Breaking the PostgreSQL Superuser Guardrails: Attacking Security-Hardening Extensions.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Les fournisseurs doivent sécuriser la frontière qu'ils vendent
Supabase a réagi rapidement, en signalant des correctifs pour quatre problèmes critiques. D'autres fournisseurs ont proposé des réponses publiques plus lentes ou floues, tandis que l'équipe principale de PostgreSQL a renvoyé la responsabilité directement aux fournisseurs de services, affirmant que le modèle de sécurité de PostgreSQL suppose que le superuser contrôle les fonctions internes.
Les lecteurs en quête d'une compréhension plus approfondie devraient consulter la recherche fondamentale de Mehmet Ince, « Breaking the PostgreSQL Superuser Guardrails ». Le projet supautils constitue également une référence essentielle, aux côtés de la documentation détaillée de Supabase sur les rôles et les opérations non prises en charge, qui reflètent désormais ces leçons.
Cet incident offre une leçon brutale pour les fournisseurs. Bloquer les opérations dangereuses par leur nom s'avère insuffisant. Une sécurité robuste exige : - des contrôles stricts sur les liaisons internes et en langage C - des autorisations de catalogue méticuleuses - une isolation plus forte au niveau du système d'exploitation
Ces mesures, et non simplement des listes de blocage plus longues, sont essentielles pour sécuriser la frontière gérée qu'ils vendent. L'intégrité du PostgreSQL cloud repose sur le fait que les fournisseurs appliquent les limites qu'ils promettent.
Foire aux questions
Quelle était la vulnérabilité de PostgreSQL géré ?
Un chercheur a contourné les restrictions des fournisseurs en enregistrant une fonction interne dangereuse de PostgreSQL sous un nom que les filtres des fournisseurs ne bloquaient pas.
La faille a-t-elle exposé le contenu des bases de données d'autres clients ?
Pas automatiquement. L'escalade démontrée a permis l'exécution de code en tant qu'utilisateur du système d'exploitation PostgreSQL sur l'hôte de la base de données, créant un point d'ancrage plutôt qu'un accès instantané aux données d'autres locataires.
S'agissait-il d'une vulnérabilité du cœur de PostgreSQL ?
L'équipe de sécurité de PostgreSQL l'a qualifiée de problème côté fournisseur : les services gérés doivent appliquer en toute sécurité les limites de privilèges qu'ils imposent.
Que devraient changer les fournisseurs de PostgreSQL géré ?
Ils devraient restreindre les liaisons dangereuses de fonctions internes et en langage C, renforcer les autorisations de catalogue et isoler les processus de base de données au niveau du système d'exploitation.