Des chercheurs de l'entreprise de sécurité JFrog ont détecté des backdoors dans le code de modèles de langage publiés sur Hugging Face, le dépôt phare de l'IA créé par la startup franco-américaine du même nom. En janvier, d'autres chercheurs ont montré qu'il était possible d'en insérer dans l'entrainement de modèles pour qu'ils répondent différemment dans des conditions bien précises.
Récemment, des chercheurs ont alerté sur deux sortes de backdoors qui peuvent se retrouver dans les modèles de langages qui permettent de créer des outils d'intelligence artificielle générative. L'une peut infecter les machines des data scientists qui utilisent les modèles, l'autre affecte les résultats attendus du modèle.
Les chercheurs de l'entreprise JFrog attirent l'attention des data scientists qui récupèrent des modèles pré-entrainés sur Hugging Face. En effet, ils ont trouvé sur cette plateforme de partage très connue dans le milieu, qui peut s'apparenter à un GitHub de l'IA, une centaine de modèles qui comportaient des backdoors ou des malwares.
Un accès total à la machine via internet
À ArsTechnica, l'équipe de JFrog a expliqué que 10 des 100 modèles problématiques trouvés étaient « véritablement malveillants » car ils effectuaient des actions compromettant la sécurité des utilisateurs.
Et l'un d'entre eux l'était particulièrement. Selon JFrog, un utilisateur dont le pseudonyme était baller423 (compte supprimé depuis) a hébergé sur Hugging Face un répertoire baller423/goober2 qui contenait un modèle PyTorch malveillant. Celui-ci permettait à l'attaquant de disposer d'un shell sur la machine compromise, mais également « de prendre le contrôle total des machines des victimes par le biais de ce que l'on appelle communément une "backdoor" (porte dérobée) » explique David Cohen, chercheur en sécurité informatique chez JFrog.
Utilisation de la sérialisation pour insérer du code binaire
Il alerte sur le fait que « cette infiltration silencieuse peut donner accès à des systèmes internes critiques et ouvrir la voie à des violations de données à grande échelle ou même à l'espionnage d'entreprises, affectant non seulement des utilisateurs individuels, mais potentiellement des organisations entières à travers le monde, tout en laissant les victimes totalement inconscientes de leur état de compromission ».
Le code du modèle goober2 utilisait le module pickle, qui, comme l'explique la documentation du module elle-même, permet de sérialiser des objets Python, c'est-à-dire créer un fichier ou un flux binaire à partir d'objets Python. Mais les fichiers pickle peuvent donc aussi contenir du code binaire :
« Le module pickle n'est pas sécurisé. Ne désérialisez des objets qu'à partir de sources fiables.
Il est possible de produire des données binaires qui exécutent du code arbitraire lors de leur désérialisation. Ne désérialisez jamais des données provenant d'une source non fiable, ou qui pourraient avoir été modifiées. »
Le code malveillant de goober2 a plus précisément été introduit via la méthode __reduce__ du module pickle, déjà connue pour permettre aux attaquants d'insérer du code Python arbitraire dans le processus de désérialisation, selon David Cohen.
Il reconnait que Hugging Face a mis en place des mesures de sécurité pour éviter ce genre d'attaques en recherchant les virus ou l'utilisation du module pickle, par exemple.
La plateforme prévient aussi dans sa documentation qu' « il existe des attaques dangereuses d'exécution de code arbitraire qui peuvent être perpétrées lorsque vous chargez un fichier pickle. Nous suggérons de charger des modèles provenant d'utilisateurs et d'organisations en qui vous avez confiance, de vous fier à des commits signés, et/ou de charger des modèles à partir des formats TF ou Jax avec le mécanisme d'auto-conversion from_tf=True. ».
Mais la mise en ligne de ce code malveillant « rappelle brutalement que la plateforme n'est pas à l'abri des menaces réelles », selon David Cohen.
Des « backdoors » sur les résultats obtenus
En janvier, d'autres chercheurs (dont certains font partie de la startup Anthropic) ont démontré que les créateurs d'un modèle peuvent modifier son comportement pour qu'il crée une réponse problématique dans des conditions bien précises.
Un modèle peut donc renvoyer un code sécurisé quand on lui dit qu'on est en 2023, mais insérer des vulnérabilités lorsque l'année indiquée est 2024. Ce comportement peut aussi toucher des réponses concernant d'autres choses que du code.
Ici, ces « backdoors » ne ciblent pas directement la machine des data scientists réutilisant des modèles, mais les utilisateurs finaux. Si ce genre de backdoors n'est pas facile à créer, il peut potentiellement se diffuser via la réutilisation de modèles infectés.
Commentaires (3)
#1
J'ai cependant l'impression que c'est une backdoor dans du code récupéré dans le modèle pré-entraîné. En quoi est-ce différent d'une backdoor dans un jeu téléchargeable ou dans n'importe quel logiciel ou encore dans une image ou vidéo ? On ne va pas faire un article pour chaque type de logiciel intégrant une backdoor, j'espère.
Le dernier point a déjà été abordé plus longuement par JM Manach et il y a un lien vers son article. Je ne vois pas l'intérêt de répéter ce qu'il y a dit. Juste une référence indiquant qu'il s'agit de backdoors de natures très différentes aurait suffit à mon avis.
#1.1
Considérant que les projets d'IA utilisant HF sont potentiellement liés à un besoin de confidentialité/souveraineté, je trouve intéressant de souligner que le petit monde opensource n'est pas bienveillant non plus, et que le vol de données (les données d'entraînement sont souvent intéressantes), l'accès à des machines de dev/ des serveurs est un bien précieux pour les pirates.
Pour autant, j'espère que ces comm ne sont pas organisées/poussées par les GAFAM qui voudraient détourner les développeurs des modèles opensource
Mais ça reste du même niveau que la surveillance des dépendances, et un gros point noir de python/nodejs et tout le dev de ce type (y compris Rust): QUI garanti que les dépendances récupérée quasi dynamiquement via internent sont "safe" avec des langages qui permettent à chaque bilbiothèque de tout faire?
Et c'est aussi un écho pour la sempiternelle mise en garde des dev: ne vous croyez pas en sécurité parce que c'est votre ordi: vous êtes exposés et vous exposez votre employeur à des menaces potentiellement gravissimes si vous n'êtes pas attentif.
#1.2
Si un groupe de pirates a accès aux machines de dev, et arrive à injecter des données dans l'entraînement de l'IA, ils peuvent créer une back door au sein du modèle de l'IA.
Par exemple: un comportement est suspect, sauf si la personne qui le perpétue a un bandana rouge.
Et pour détecter un backdoor de ce type dans un modèle, il faut devenir un spécialiste des eIRM :)