Une faille d’injection rapide dans l’IDE Antigravity de Google transforme un outil de recherche de fichiers en un vecteur d’exécution de code à distance, contournant les protections du mode sécurisé.
Des chercheurs en sécurité ont révélé une faille d’injection rapide dans l’IDE Antigravity de Google qui pourrait être utilisée pour contourner les protections du bac à sable et réaliser l’exécution de code à distance (RCE).
Le problème venait de la capacité d’Antigravity à permettre aux agents IA d’invoquer des fonctions natives, comme la recherche de fichiers, au nom de l’utilisateur. Conçue pour éliminer la complexité, cette fonctionnalité pourrait permettre aux attaquants d’injecter des entrées malveillantes dans un paramètre d’outil.
Selon les chercheurs de Pillar Security, la vulnérabilité pourrait contourner la « configuration de sécurité la plus restrictive » d’Antigravity, le mode sécurisé.
La recherche de fichiers pourrait être transformée en exécution de code
Le vecteur d’injection rapide de Pillar reposait sur l’outil « find_my_name » d’Antigravity et sur un utilitaire « fd » intégré. find_my_name est l’un des outils d’agent intégrés d’Antigravity qui permet à l’IA de rechercher des fichiers et des répertoires dans l’espace de travail du projet à l’aide de la ligne de commande fd.
Ce qui se passait, c’est que toute chaîne commençant par « – » était interprétée par fd comme un indicateur plutôt que comme un modèle de recherche, permettant l’exécution de binaires dans des fichiers correspondant à un modèle « -Xsh ». « La technique exploite une vérification insuffisante des entrées du paramètre Pattern de l’outil find_by_name, permettant aux attaquants d’injecter des indicateurs de ligne de commande dans l’utilitaire fd sous-jacent, convertissant ainsi une opération de recherche de fichier en exécution de code arbitraire », ont déclaré les chercheurs dans un article de blog.
Essentiellement, au lieu de simplement localiser des fichiers, « fd » pourrait être amené à exécuter des fichiers binaires fournis par un attaquant sur ces fichiers à l’aide d’une invite spécialement conçue qui manipule le paramètre « Pattern ». Les chercheurs l’ont démontré en créant un fichier dans le répertoire local avec l’invite malveillante pour exploiter le « modèle » injecté. Antigravity a récupéré le fichier, exécuté les tâches prévues (comme lancer la calculatrice) et a également lancé l’outil de recherche, désormais prêt à exécuter les modèles « -Xsh ».
Cela pourrait également être transformé en exécution de code à distance via une injection d’invite indirecte. « Un utilisateur extrait un fichier source d’apparence inoffensive d’une origine non fiable, telle qu’un référentiel public, contenant des commentaires contrôlés par l’attaquant qui demandent à l’agent d’organiser et de déclencher l’exploit », ont expliqué les chercheurs.
Le pire, c’est que c’était imparable avec la protection existante.
Le bac à sable de Google n’a jamais eu de chance
Le mode sécurisé d’Antigravity, conçu pour restreindre l’accès au réseau, empêcher les écritures hors de l’espace de travail et garantir que toutes les opérations de commande s’exécutent strictement dans un contexte sandbox, n’a pas pu signaler ou mettre en quarantaine cette technique. En effet, l’outil find_my_name est appelé bien avant que les restrictions du mode sécurisé ne soient évaluées.
« L’agent le traite comme une invocation d’outil natif, et non comme une commande shell, de sorte qu’il n’atteint jamais la limite de sécurité imposée par le mode sécurisé », ont noté les chercheurs.
Le problème a été réduit à une double cause fondamentale. Une « Aucune validation d’entrée » au niveau du paramètre Pattern, qui accepte des chaînes arbitraires sans vérifier les caractères de modèle de recherche légitimes. La seconde était la « terminaison sans argument », qui fait référence à l’incapacité de fd à faire la distinction entre les indicateurs et les termes de recherche. Google a déjà corrigé la faille en interne et les utilisateurs d’Antigravity n’ont rien d’autre à faire pour rester protégés. Cependant, la capacité de la faille à contourner le mode sécurisé, soulignent les chercheurs de Pillar, souligne que les contrôles de sécurité axés sur les commandes shell sont insuffisants. « L’industrie doit aller au-delà des contrôles basés sur la désinfection et s’orienter vers l’isolement des exécutions », ont-ils déclaré. « Chaque paramètre d’outil natif qui atteint une commande shell est un point d’injection potentiel. »
