Google aurait corrigé une faille dans le SDK Vertex AI pour Python qui pourrait permettre aux attaquants de détourner les téléchargements de modèles et de déclencher l’exécution de code à distance entre les locataires.
Un défaut de conception dans le kit de développement logiciel (SDK) Vertex AI pour Python, la plate-forme gérée de Google Cloud pour la création, la formation et le déploiement d’agents IA, pourrait permettre le détournement et l’empoisonnement de modèles en dehors du propre projet Google Cloud d’un développeur.
Selon les chercheurs de l’Unité 42, une combinaison de mauvaise logique de dénomination de compartiment et d’authentification manquante a permis à un attaquant de détourner le projet de la victime simplement en connaissant son ID de projet et sa région.
« Étant donné qu’il n’existe pas deux buckets dans l’ensemble de Google Cloud qui puissent partager le même nom, un attaquant capable de prédire le nom d’un bucket peut le créer de manière préventive dans son propre projet », ont déclaré les chercheurs dans un article de blog. « Toute tentative ultérieure d’utiliser un bucket portant ce nom, même à partir d’un projet différent, revient silencieusement au bucket de l’attaquant. »
Les chercheurs ont déclaré qu’il s’agit d’une classe connue de vulnérabilité qui « tire parti du caractère unique à l’échelle mondiale » des noms de compartiments de stockage cloud. Ils l’appelaient « Bucket Squatting ».
Une exploitation réussie pourrait injecter un modèle malveillant qui serait chargé par l’infrastructure Vertex AI, entraînant l’exécution de code entre les locataires. La faille a été signalée à Google, qui aurait résolu le problème sous-jacent.
désérialisation pickle pour RCE multi-locataires
Selon l’unité 42, le workflow de modèle vulnérable dans Vertex AI SDK pour Python versions 1.139.0 et 1.140.0 reposait sur un nom de bucket intermédiaire dérivé exclusivement de l’ID de projet et de la région d’un client. Lorsqu’un compartiment portant ce nom existait déjà, le SDK vérifiait uniquement son existence et n’en confirmait pas la propriété.
Cela a créé un scénario de bucket-squatting dans lequel un attaquant pourrait pré-créer un bucket correspondant au bucket intermédiaire attendu par une victime et attendre que les téléchargements de modèles y soient dirigés. Une fois qu’un artefact de modèle était téléchargé dans le compartiment contrôlé par l’attaquant, celui-ci pouvait le remplacer par une version malveillante pendant une étroite fenêtre de condition de concurrence avant que l’agent de service de Vertex AI ne le récupère.
L’attaque pourrait se transformer en RCE, car les modèles d’apprentissage automatique en Python sont généralement stockés à l’aide des formats de sérialisation Pickle ou Joblib. Étant donné que la désérialisation pickle peut exécuter du code arbitraire via des objets spécialement conçus, un modèle empoisonné pourrait exécuter du code à distance lorsqu’il est chargé par l’infrastructure de service de Vertec AI.
Ce processus d’exploitation entre locataires a été surnommé « Pickle in the Middle » par les chercheurs car il dépendait, en partie, de la désérialisation du module pickle intégré de Python.
Google a corrigé le bug recherché par l’IA
Dans le cadre de la recherche, l’unité 42 a intégré un grand modèle de langage (LLM) dans son flux de travail d’analyse de code pour accélérer la découverte des vulnérabilités.
« Les analyses qui prenaient autrefois plusieurs jours peuvent désormais être exécutées beaucoup plus rapidement », ont déclaré les chercheurs. « En affinant de manière itérative le modèle et en lui demandant de rechercher des modèles spécifiques, nous avons trouvé des chemins menant à des ressources provisionnées sur le cloud, affectées par des entrées contrôlées par l’utilisateur ou dérivées du projet. »
Google aurait modifié le flux de travail concerné afin que les compartiments de préparation soient désormais validés avant utilisation, empêchant ainsi les attaquants d’enregistrer des noms de compartiment qui pourraient être confondus avec des ressources appartenant à d’autres projets.
Les correctifs ont été déployés dans les versions 1.144.0 et 1.148.0 du SDK, et les utilisateurs doivent effectuer une mise à niveau vers l’une des versions corrigées.
