Snowflake permet une exécution de code à distance via PostgreSQL

Contexte de la vulnérabilité

Les chercheurs de Varonis ont étudié l’instance PostgreSQL fournie par Snowflake, où le rôle snowflake_admin est déclaré non‑superutilisateur. Malgré cette limitation, le rôle possède la capacité CREATEROLE, ce qui lui permet de créer ou modifier d’autres rôles. Cette configuration de base constitue le point d’ancrage de l’escalade, car elle expose les privilèges internes de PostgreSQL à un compte qui ne devrait pas disposer d’un accès système.

Mécanisme d’escalade

Le groupe a identifié une chaîne de cinq fonctionnalités documentées de PostgreSQL. Premièrement, le rôle snowflake_admin utilise CREATEROLE pour s’attribuer le droit pg_write_all_data. Ensuite, il détourne un job pg_cron préexistant, le faisant s’exécuter sous l’identité postgres. La troisième étape consiste à rebondir des fonctions bloquées via le langage internal, ce qui contourne les restrictions imposées sur les fonctions C. Enfin, la chaîne modifie la variable archive_command, permettant d’injecter du code arbitraire qui s’exécute au niveau du système d’exploitation.

Conséquences techniques

En manipulant archive_command, l’attaquant obtient un accès complet au système d’exploitation de l’hôte PostgreSQL. Cette position lui donne la possibilité d’extraire les clés mTLS propres à chaque locataire ainsi que les identifiants temporaires AWS STS, compromettant ainsi la confidentialité des données et la segmentation entre clients. L’exploitation ne nécessite aucune désactivation de mesures de mitigation publiées, ce qui montre que les contrôles existants ne couvrent pas la combinaison de ces cinq fonctionnalités.

Mesures d’atténuation

Snowflake a corrigé la faille côté serveur, supprimant la capacité d’escalade pour le rôle snowflake_admin. Pour les organisations qui déploient leur propre PostgreSQL, il est recommandé de traiter CREATEROLE comme un privilège quasi‑superutilisateur, d’interdire le langage internal ainsi que la création de fonctions C, et d’auditer régulièrement les jobs pg_cron et les fonctions définies avec SECURITY DEFINER. Ces actions limitent la surface d’attaque et empêchent la reconstitution d’une chaîne similaire.