Nécessite Docker. Utilise les images -alpine (moteur fonctionnellement identique).

Multi-moteurs (famille MySQL + SQL Server)

L'étude est reproduite sur deux familles de moteurs supplémentaires. Famille MySQL (MariaDB, modèle de trigger DEFINER) dans scripts/mysql/ :

SQL Server (modèle de chaînage de propriété) dans scripts/mssql/ — s'exécute sur une instance LocalDB locale via sqlcmd hôte (pas de Docker ; l'attaquant à faibles privilèges est modélisé par l'usurpation EXECUTE AS USER) :

Réserve de reproductibilité (SQL Server). Contrairement aux moteurs Docker, le volet SQL Server a une dépendance hôte : il s'exécute sur une instance locale SQL Server LocalDB via sqlcmd (chemin codé en dur dans run_matrix_mssql.sh), il est donc exclusivement Windows et ne peut pas être épinglé à un digest d'image. L'attaquant à faibles privilèges est modélisé par l'usurpation EXECUTE AS USER (LocalDB n'accepte que l'authentification Windows). Les résultats sur le comportement du moteur (DISABLE sans trace résiduelle ; la garde DDL ne détecte pas DISABLE) sont indépendants du type de session et vaudraient pour une vraie connexion ; les résultats sur les octrois d'objets sont appliqués fidèlement par l'usurpation. C'est le moins portable des trois moteurs — constaté en toute honnêteté.

Résultat principal multi-moteurs : la classe d'ombre search_path (1A/1B) ne se transpose ni à MySQL ni à SQL Server (pas de search_path), contrairement au remplacement de trigger, au contournement dormant et à l'empoisonnement de l'attribution. La liaison des privilèges DEFINER de MySQL rend l'aveuglement plus détectable ; SQL Server, comme PostgreSQL, permet une restauration octet pour octet et ajoute une primitive DISABLE TRIGGER sans trace résiduelle que sa propre défense DDL ne détecte pas. Comparaison complète des trois moteurs dans FINDINGS.md.

Arborescence

Résultat principal

• 1A planter une ombre dans un schéma nouveau — échoue à la mise en place (un rôle fraîchement créé ne peut pas CREATE SCHEMA), pas parce que « pg_catalog gagne ». Planter dans le public déjà inscriptible fait bien de l'ombre : 1S (même signature, ordre des schémas) et 1T (la surcharge exacte bat la fonction intégrée même avec pg_catalog en premier — isole la spécificité de type) aveuglent tous deux (payload nul).
• 1B surcharge exacte de row_to_json pour type composite — aveugle l'auditeur lorsque public est inscriptible et que le search_path du trigger n'est pas épinglé. Atteignable sur PostgreSQL standard ≤14 ; conditionné par une mauvaise configuration sur 15+. Épingler search_path le neutralise partout.
• 1C remplacer une fonction d'audit détenue par l'application — aveugle, et est réversible avec un diff d'objets propre (rejeu à l'identique de la source) — mais un canari écriture-vs-audit et un trigger d'événement DDL le détectent quand même.
• La dormance conditionnée par GUC et l'empoisonnement de l'attribution en base fonctionnent tous deux sous leurs préconditions (de mauvaise configuration) ; la ligne d'audit fabriquée est impossible à distinguer en ne consultant que la table d'audit.
• La journalisation au niveau moteur (pgaudit/log_statement) + le puits chaîné par hachage sont les défenses qui bouclent l'ensemble.

Posture de divulgation responsable

Reproduit sur PostgreSQL standard dans un laboratoire local avec des données anonymisées/synthétiques. Le SQL d'attaque est cantonné au schéma de laboratoire construit ici ; il s'agit d'une étude de faisabilité/défense, pas d'un payload militarisé. Les primitives sous-jacentes sont déjà publiques (CVE-2018-1058 ; escalade search_path sur SECURITY DEFINER) — la contribution réside dans la composition et l'évaluation des défenses. Aucun système réel n'est identifié.