Problème 5065

L'essor des outils de génération de code basés sur le LLM transforme la façon dont les développeurs écrivent des logiciels, et introduit ainsi de nouveaux risques pour la chaîne d'approvisionnement logicielle.

Ces assistants de codage IA, comme les grands modèles de langage en général, ont tendance à halluciner. Ils suggèrent du code qui intègre des packages logiciels inexistants.

Comme nous l'avons souligné en mars et en septembre l'année dernière, des chercheurs en sécurité et des universitaires ont découvert que les assistants de codage IA inventent des noms de packages. Dans une étude récente, les chercheurs ont constaté qu'environ 5,2 % des suggestions de packages issues de modèles commerciaux n'existaient pas, contre 21,7 % issues de modèles open source ou disponibles gratuitement.

L'exécution de ce code devrait entraîner une erreur lors de l'importation d'un package inexistant. Mais les malfaiteurs ont compris qu'ils pouvaient détourner l'hallucination à leur profit.

Il suffit de créer un package malveillant sous un nom de package halluciné, puis de télécharger le package malveillant dans un registre ou un index de packages comme PyPI ou npm pour le distribuer. Par la suite, lorsqu'un assistant de code IA ré-hallucine le nom récupéré, le processus d'installation des dépendances et d'exécution du code exécutera le malware.

La récurrence semble suivre un schéma bimodal : certains noms hallucinés apparaissent de manière répétée lorsque les invites sont réexécutées, tandis que d'autres disparaissent complètement, ce qui suggère que certaines invites produisent systématiquement les mêmes packages fantômes.

Comme l'a récemment souligné l'entreprise de sécurité Socket, les chercheurs universitaires qui ont étudié le sujet l'année dernière ont découvert que la réexécution dix fois de la même invite déclenchant une hallucination entraînait la répétition systématique de 43 % des paquets hallucinés et leur disparition définitive de 39 %.

L'exploitation de noms de paquets hallucinés constitue une forme de typosquatting, où des variantes ou des fautes d'orthographe de termes courants sont utilisées pour tromper les utilisateurs. Seth Michael Larson, développeur en sécurité en résidence à la Python Software Foundation, a baptisé ce phénomène « slopsquatting », « slop » étant un terme péjoratif courant pour désigner les résultats des modèles d'IA.

« Nous n'en sommes qu'aux prémices de l'étude de ce problème au niveau de l'écosystème », a déclaré Larson à The Register. « Il est difficile, voire impossible, de quantifier le nombre de tentatives d'installation dues aux hallucinations LLM sans plus de transparence de la part des fournisseurs LLM. Les utilisateurs de code, de packages et d'informations générés par LLM devraient vérifier les résultats LLM par rapport à la réalité avant de les exploiter, sous peine d'avoir des conséquences concrètes. »

Larson a expliqué que de nombreuses raisons peuvent amener un développeur à tenter d'installer un package inexistant, notamment une erreur de frappe dans le nom du package, une installation incorrecte de packages internes sans vérifier si ces noms existent déjà dans un index public (confusion de dépendances), des différences entre le nom du package et celui du module, etc.

« Nous constatons un réel changement dans la façon dont les développeurs écrivent du code », a déclaré Feross Aboukhadijeh, PDG de l'entreprise de sécurité Socket, à The Register. Les outils d'IA devenant l'assistant par défaut de beaucoup, le « codage vibratoire » est monnaie courante. Les développeurs sollicitent l'IA, copient la suggestion et passent à autre chose. Ou pire, l'agent IA installe lui-même les paquets recommandés.

Le problème, c'est que ces suggestions de code incluent souvent des noms de paquets hallucinés qui semblent réels, mais qui n'existent pas. J'en ai été témoin. Vous le collez dans votre terminal et l'installation échoue – ou pire, elle ne l'est pas, car quelqu'un a piraté le nom exact du paquet.

Aboukhadijeh explique que ces faux paquets peuvent paraître très convaincants.

« Lorsque nous enquêtons, nous trouvons parfois des fichiers README réalistes, de faux dépôts GitHub, et même des blogs douteux qui font passer le paquet pour authentique », explique-t-il, ajoutant que les analyses de sécurité de Socket détectent ces paquets car elles analysent le fonctionnement du code.

Dans quel monde vivons-nous ! Les paquets créés par l'IA sont validés et approuvés par une autre IA trop empressée pour être utile.

« Pire encore, lorsque vous recherchez sur Google l'un de ces noms de paquets piratés, vous obtenez souvent un résumé généré par l'IA, provenant de Google lui-même, vantant avec assurance le paquet, affirmant qu'il est utile, stable et bien maintenu. Mais il ne fait que répéter le fichier README du paquet, sans scepticisme ni contexte. Pour un développeur pressé, cela donne un faux sentiment de légitimité.

« Dans quel monde vivons-nous ! Les paquets créés par l'IA sont validés et approuvés sans discussion par une autre IA, trop empressée de se rendre utile. »

Aboukhadijeh a évoqué un incident survenu en janvier : [https://socket.dev/blog/gmail-for-exfiltration-malicious-npm-packages-target-solana-private-keys-and-drain-victim-s], où l'aperçu de l'IA de Google, qui répond aux requêtes de recherche avec du texte généré par l'IA, a suggéré un paquet npm malveillant @async-mutex/mutex, qui squattait le paquet légitime async-mutex.

Il a également noté qu'un acteur malveillant utilisant le nom « _Iain » a récemment publié un guide sur un forum du dark web expliquant comment créer un botnet basé sur la blockchain à l'aide de paquets npm malveillants.

Aboukhadijeh a expliqué que _Iain « a automatisé la création de milliers de paquets piratés (dont beaucoup ciblaient des bibliothèques de chiffrement) et a même utilisé ChatGPT pour générer à grande échelle des variantes réalistes de noms de paquets réels. Il a partagé des tutoriels vidéo expliquant le processus, de la publication des paquets à l'exécution des charges utiles sur des machines infectées via une interface graphique. C'est un exemple clair de la façon dont les attaquants instrumentalisent l'IA pour accélérer les attaques contre la chaîne d'approvisionnement logicielle. »

Larson a déclaré que la Python Software Foundation s'efforce constamment de rendre l'utilisation abusive des paquets plus difficile, ajoutant que ce travail nécessite du temps et des ressources.

« Alpha-Omega a sponsorisé le travail de Mike Fiedler, notre ingénieur sécurité et sûreté PyPI, afin de réduire les risques de malware sur PyPI, notamment en implémentant une API programmatique pour signaler les malwares, en collaborant avec les équipes de signalement de malwares existantes et en améliorant la détection du piratage typographique des projets phares », a-t-il déclaré.

Les utilisateurs de PyPI et les gestionnaires de paquets en général doivent vérifier que le paquet qu'ils installent est un paquet existant et bien connu, que son nom est correct et que son contenu a été vérifié avant l'installation. Mieux encore, les organisations peuvent dupliquer un sous-ensemble de PyPI au sein de leur propre organisation afin de mieux contrôler les paquets disponibles pour les développeurs.