Logo Zéphyrnet

Dans la précipitation pour créer des applications d'IA, ne laissez pas la sécurité de côté

Date :

Fonctionnalité Alors qu’ils sont pressés de comprendre, de créer et de commercialiser des produits d’IA, les développeurs et les data scientists sont invités à être attentifs à la sécurité et à ne pas être la proie d’attaques sur la chaîne d’approvisionnement.

Il existe d’innombrables modèles, bibliothèques, algorithmes, outils prédéfinis et packages avec lesquels jouer, et les progrès sont incessants. Le résultat de ces systèmes est peut-être une autre histoire, même s’il est indéniable qu’il y a toujours quelque chose de nouveau avec lequel jouer, au moins.

Peu importe toute l'excitation, le battage médiatique, la curiosité et la peur de rater quelque chose, la sécurité ne peut être oubliée. Si ce n'est pas un choc pour vous, c'est fantastique. Mais un rappel est utile ici, d'autant plus que les technologies d'apprentissage automatique ont tendance à être mises au point par des scientifiques plutôt que par des ingénieurs, du moins pendant la phase de développement, et même si ces personnes connaissent des choses comme les architectures de réseaux neuronaux, la quantification, etc. Techniques de formation des générations, l'infosec n'est naturellement peut-être pas leur point fort.

Réaliser un projet d’IA n’est pas très différent de la construction de n’importe quel autre logiciel. Vous regrouperez généralement des bibliothèques, des packages, des données d’entraînement, des modèles et du code source personnalisé pour effectuer des tâches d’inférence. Les composants de code disponibles dans les référentiels publics peuvent contenir des portes dérobées ou des exfiltrateurs de données cachés, et les modèles et ensembles de données prédéfinis peuvent être empoisonnés pour provoquer un comportement inattendu et inapproprié des applications.

En fait, certains modèles peuvent contenir des logiciels malveillants réalisé si leur contenu n'est pas désérialisé en toute sécurité. La sécurité des plugins ChatGPT a également entrer sous un examen minutieux.

En d’autres termes, les attaques contre la chaîne d’approvisionnement que nous avons constatées dans le monde du développement de logiciels peuvent se produire au pays de l’IA. De mauvais packages pourraient conduire à la compromission des postes de travail des développeurs, entraînant des intrusions dommageables dans les réseaux d'entreprise, et des modèles et des ensembles de données de formation falsifiés pourraient amener les applications à classer incorrectement les éléments, à offenser les utilisateurs, etc. Les bibliothèques et modèles détournés ou enrichis de logiciels malveillants, s'ils sont intégrés aux logiciels livrés, pourraient également exposer les utilisateurs de ces applications aux attaques.

Ils résoudront un problème mathématique intéressant, puis ils le déploieront et c'est tout. Ce n'est pas un test de stylet, il n'y a pas d'équipe rouge IA

En réponse, des startups de cybersécurité et d’IA émergent spécifiquement pour lutter contre cette menace ; il ne fait aucun doute que les joueurs établis y ont également un œil, du moins nous l’espérons. Les projets d'apprentissage automatique doivent être audités et inspectés, testés pour leur sécurité et évalués pour leur sécurité.

« [L’IA] est issue du monde universitaire. Il s'agit en grande partie de projets de recherche universitaires ou de petits projets de développement de logiciels qui ont été largement lancés par des universitaires ou de grandes entreprises, et qui n'ont tout simplement pas de sécurité interne », Tom Bonner, vice-président de la recherche chez HiddenLayer, l'un des une telle startup axée sur la sécurité, a déclaré Le registre.

« Ils résoudront un problème mathématique intéressant à l'aide d'un logiciel, puis ils le déploieront et c'est tout. Il n’y a pas de test d’intrusion, pas d’équipe rouge d’IA, d’évaluation des risques ou de cycle de vie de développement sécurisé. Tout d’un coup, l’IA et l’apprentissage automatique ont vraiment décollé et tout le monde cherche à s’y lancer. Ils récupèrent tous les progiciels courants issus du monde universitaire et voilà, ils sont pleins de vulnérabilités, pleins de failles.

La chaîne d'approvisionnement de l'IA comporte de nombreux points d'entrée pour les criminels, qui peuvent utiliser des éléments tels que le typosquattage pour inciter les développeurs à utiliser des copies malveillantes de bibliothèques par ailleurs légitimes, permettant ainsi aux escrocs de voler des données sensibles et des informations d'identification d'entreprise, de détourner des serveurs exécutant le code, et bien plus encore, affirme-t-on. Les défenses de la chaîne d’approvisionnement logicielle devraient également être appliquées au développement de systèmes d’apprentissage automatique.

"Si vous pensez à un diagramme circulaire montrant comment vous allez être piraté une fois que vous aurez ouvert un département d'IA dans votre entreprise ou organisation", a déclaré Dan McInerney, chercheur principal en sécurité de l'IA chez Protect AI. Le registre, « une infime fraction de ce gâteau sera constituée d’attaques d’entrée de modèle, ce dont tout le monde parle. Et une grande partie va s’attaquer à la chaîne d’approvisionnement – ​​les outils que vous utilisez pour construire vous-même le modèle.

Les attaques d'entrée étant façons intéressantes que les gens peuvent casser les logiciels d'IA en utilisant.

Pour illustrer le danger potentiel, HiddenLayer l'autre semaine mis en évidence ce qu'il croit fermement est un problème de sécurité avec un service en ligne fourni par Hugging Face qui convertit les modèles au format Pickle dangereux en un format plus sécurisé. Safetenseurs, également développé par Hugging Face.

Les modèles Pickle peuvent contenir des logiciels malveillants et d'autres codes arbitraires qui pourraient être exécutés silencieusement et de manière inattendue lors de la désérialisation, ce qui n'est pas génial. Safetensors a été créé comme une alternative plus sûre : les modèles utilisant ce format ne devraient pas finir par exécuter du code intégré lorsqu'ils sont désérialisés. Pour ceux qui ne le savent pas, Hugging Face héberge des centaines de milliers de modèles de réseaux neuronaux, d'ensembles de données et de morceaux de code que les développeurs peuvent télécharger et utiliser en quelques clics ou commandes.

Le convertisseur Safetensors s'exécute sur l'infrastructure Hugging Face et peut être invité à convertir un modèle PyTorch Pickle hébergé par Hugging Face en une copie au format Safetensors. Mais ce processus de conversion en ligne lui-même est vulnérable à l’exécution de code arbitraire, selon HiddenLayer.

Les chercheurs de HiddenLayer ont déclaré avoir découvert qu'ils pouvaient soumettre une demande de conversion pour un modèle Pickle malveillant contenant du code arbitraire, et que pendant le processus de transformation, ce code serait exécuté sur les systèmes de Hugging Face, permettant à quelqu'un de commencer à jouer avec le robot convertisseur et ses utilisateurs. Si un utilisateur convertissait un modèle malveillant, son jeton Hugging Face pourrait être exfiltré par le code caché, et « nous pourrions en effet voler son jeton Hugging Face, compromettre son référentiel et afficher tous les référentiels privés, ensembles de données et modèles que cet utilisateur possède ». accès à », a soutenu HiddenLayer.

De plus, on nous dit que les informations d'identification du robot convertisseur pourraient être consultées et divulguées par un code caché dans un modèle Pickle, permettant à quelqu'un de se faire passer pour le robot et d'ouvrir des demandes d'extraction pour des modifications dans d'autres référentiels. Ces modifications pourraient introduire du contenu malveillant si elles sont acceptées. Nous avons demandé à Hugging Face une réponse aux conclusions de HiddenLayer.

"Ironiquement, le service de conversion vers Safetensors était lui-même terriblement peu sécurisé", nous a dit Bonner de HiddenLayer. « Compte tenu du niveau d’accès du robot de conversion aux référentiels, il était en fait possible de voler le jeton qu’il utilise pour soumettre des modifications via d’autres référentiels.

« Donc, en théorie, un attaquant aurait pu soumettre n'importe quelle modification à n'importe quel référentiel et faire croire qu'elle provenait de Hugging Face, et une mise à jour de sécurité aurait pu le tromper et l'accepter. Les gens auraient simplement eu des modèles détournés ou des modèles non sécurisés dans leurs dépôts et ne le sauraient pas.

C'est plus qu'une menace théorique : Devops shop JFrog a dit qu'il avait trouvé code malveillant caché dans 100 modèles hébergés sur Hugging Face.

Il existe en réalité différentes manières de masquer des charges utiles de code nuisibles dans des modèles qui, selon le format de fichier, sont exécutés lorsque les réseaux neuronaux sont chargés et analysés, permettant ainsi aux malfaiteurs d'accéder aux machines des utilisateurs. Les modèles PyTorch et Tensorflow Keras « présentent le risque potentiel le plus élevé d’exécution de code malveillant car ce sont des types de modèles populaires avec des techniques d’exécution de code connues qui ont été publiées », a noté JFrog.

Recommandations non sécurisées

Les programmeurs qui utilisent des assistants suggérant du code pour développer des applications doivent également être prudents, a prévenu Bonner, sinon ils pourraient finir par incorporer du code non sécurisé. GitHub Copilot, par exemple, a été formé sur des référentiels open source, et au moins 350,000 XNUMX d'entre eux sont potentiellement vulnérables à un ancien problème de sécurité impliquant Python et les archives tar.

Python fichier tar Le module, comme son nom l'indique, aide les programmes à décompresser les archives tar. Il est possible de créer un .tar de telle sorte que lorsqu'un fichier de l'archive est extrait par le module Python, il tente d'écraser un fichier arbitraire sur le système de fichiers de l'utilisateur. Cela peut être exploité pour détruire les paramètres, remplacer les scripts et provoquer d’autres méfaits.

La faille a été repérée en 2007 et mis en évidence à nouveau en 2022, ce qui a incité les gens à lancer des projets de correctifs pour éviter cette exploitation. Ces mises à jour de sécurité n'ont peut-être pas été intégrées aux ensembles de données utilisés pour entraîner de grands modèles de langage à programmer, a déploré Bonner. "Donc, si vous demandez à un LLM d'aller décompresser un fichier tar maintenant, il vous renverra probablement [l'ancien] code vulnérable."

Bonner a exhorté la communauté de l'IA à commencer à mettre en œuvre des pratiques de sécurité de la chaîne d'approvisionnement, telles que demander aux développeurs de prouver numériquement qu'ils sont bien ceux qu'ils prétendent être lorsqu'ils apportent des modifications aux référentiels de codes publics, ce qui rassurerait les gens sur le fait que les nouvelles versions des choses ont été produites par des développeurs légitimes. et il ne s'agissait pas de changements malveillants. Cela obligerait les développeurs à sécuriser tout ce qu'ils utilisent pour s'authentifier afin que quelqu'un d'autre ne puisse pas se faire passer pour eux.

Et tous les développeurs, petits et grands, devraient effectuer des évaluations de sécurité, inspecter les outils qu'ils utilisent, et tester leurs logiciels avant leur déploiement.

Essayer de renforcer la sécurité dans la chaîne d'approvisionnement de l'IA est délicat, et avec autant d'outils et de modèles créés et publiés, il est difficile de suivre le rythme.

McInerney de Protect AI a souligné que « c'est un peu l'état dans lequel nous nous trouvons actuellement. Il existe de nombreuses solutions faciles à trouver partout. Il n’y a tout simplement pas assez de personnel pour s’occuper de tout cela parce que tout va si vite. » ®

spot_img

Dernières informations

spot_img