L’outil, créé par des chercheurs universitaires, est conçu pour trouver et créer automatiquement un patch de vulnérabilités dans de grands référentiels comme Github, mais il n’est pas encore parfait.
Les chercheurs en sécurité néerlandais et iraniens ont créé un outil Genai automatisé qui peut numériser d’énormes référentiels open source et un code vulnérable patch qui pourrait compromettre les applications.
Testé en scannant Github pour une vulnérabilité de traversée de trajet particulière dans les projets Node.js qui existe depuis 2010, l’outil a identifié 1 756 projets vulnérables, certains décrits comme «très influents» et ont conduit à 63 projets corrigés jusqu’à présent.
L’outil ouvre la possibilité pour les plates-formes Genai comme Chatgpt pour créer et distribuer automatiquement des correctifs dans des référentiels de code, augmentant considérablement la sécurité des applications open source.
Mais la recherche, décrite dans un article récemment publié, souligne également une sérieuse limitation dans l’utilisation de l’IA qui devra être fixée pour que cette solution soit efficace. Alors que le correctif automatisé par un modèle grand langage (LLM) améliore considérablement l’évolutivité, le correctif pourrait également introduire d’autres bogues.
Et il pourrait être difficile d’éradiquer pleinement la vulnérabilité particulière sur laquelle ils ont travaillé car, après 15 ans d’exposition, certains modèles de langage populaire (LLM) semblent avoir été empoisonnés avec.
Pourquoi? Parce que les LLM sont formées sur les bases de code open source, où ce bogue est enterré.
En fait, les chercheurs ont constaté que si un LLM est contaminé par un modèle de code source vulnérable, il générera ce code même lorsqu’il est invité à synthétiser le code sécurisé. Ainsi, disent les chercheurs, une leçon est que les modèles de code vulnérables populaires doivent être éradiqués non seulement à partir de projets open-source et de ressources des développeurs, mais aussi de LLMS, «qui peut être une tâche très difficile».
Les pirates plantent du mauvais code depuis des années
Les acteurs de la menace plantent des vulnérabilités dans les référentiels open source depuis des années, en espérant qu’avant que les bogues ne soient découverts, ils peuvent être utilisés pour infiltrer les organisations adoptant des applications open source. Le problème: les développeurs copient et collent sans le savoir le code vulnérable à partir de plates-formes de partage de code telles que Stack Overflow, qui pénètre ensuite dans les projets GitHub.
Les attaquants n’ont besoin de connaître qu’un seul modèle de code vulnérable pour pouvoir attaquer avec succès de nombreux projets et leurs dépendances en aval, notent les chercheurs.
La solution créée par les chercheurs pourrait permettre la découverte et l’élimination des trous open source à grande échelle, pas seulement dans un projet à la fois comme c’est le cas maintenant.
Cependant, l’outil n’est pas «à parcourir une fois, corriger tout», car les développeurs fournissent souvent des référentiels sans contribuer aux projets originaux. Cela signifie qu’une vulnérabilité d’être vraiment effacée, tous les référentiels avec un morceau de code vulnérable devraient être scannés et corrigés.
De plus, le modèle de code vulnérable étudié dans cette recherche a utilisé directement le nom de chemin de l’URL, sans aucune mise en forme spéciale, créant une faille facile à exploiter. C’est le modèle sur lequel l’outil se concentre; D’autres placements du mauvais code ne sont pas détectés.
Les chercheurs publieront l’outil en août lors d’une conférence de sécurité au Vietnam. Ils prévoient de l’améliorer et de l’étendre dans plusieurs directions, en particulier en intégrant d’autres modèles de code vulnérables et en améliorant la génération de patchs.
Expert sceptique
Cependant, Robert Beggs, responsable de la société canadienne de réponse aux incidents, DigitalDence, est sceptique quant à la valeur de l’outil dans son état actuel.
L’idée d’un outil automatisé pour analyser et corriger le code malveillant existe depuis un certain temps, a-t-il souligné, et il attribue aux auteurs d’avoir tenté de résoudre bon nombre des problèmes possibles déjà soulevés.
Mais, a-t-il ajouté, la recherche ne traite toujours pas de questions telles que qui est responsable si un correctif défectueux endommage un projet public, et si un gestionnaire de référentiel peut reconnaître qu’un outil d’IA essaie d’insérer ce qui peut être une vulnérabilité dans une application?
Lorsqu’il a été suggéré que la direction devrait approuver l’utilisation d’un tel outil, Beggs s’est demandé comment les managers sauraient que l’outil est digne de confiance et – encore – qui serait responsable si le patch était mauvais?
Il n’est pas non plus clair dans quelle mesure, le cas échéant, les tests post-retrait que l’outil fera pour s’assurer que le patch ne fait pas plus de dégâts. Le journal indique qu’en fin de compte, la responsabilité de s’assurer que le correctif est correct réside dans les responsables du projet. La partie AI de l’outil crée un patch, calcule un score CVSS et soumet un rapport aux responsables du projet.
Les chercheurs «ont un excellent processus et je leur accorde un crédit total pour un outil qui a beaucoup de capacités. Cependant, je ne toucherais personnellement pas l’outil car il traite de la modification du code source», a déclaré Beggs, ajoutant: «Je ne pense pas que l’intelligence artificielle soit au niveau de la permettre de gérer le code source pour un grand nombre d’applications.»
Cependant, a-t-il admis que les documents académiques ne sont généralement que la première passe à un problème.
Les développeurs open source peuvent faire partie du problème
En cours de route, les chercheurs ont également découvert un fait inquiétant: les développeurs d’applications open source ignorent parfois les avertissements que certains extraits de code sont radioactifs.
Le code vulnérable que les chercheurs voulaient résoudre dans autant de projets GitHub possibles datés de 2010, et se trouve dans Github Gist, un service de partage d’extraits de code. Le code crée un serveur de fichiers HTTP statique pour les applications Web Node.js. « (Pourtant) Malgré sa simplicité et sa popularité, de nombreux développeurs semblent ignorer que ce modèle de code est vulnérable à l’attaque de traversée de chemin », écrivent les chercheurs.
Même ceux qui ont reconnu le problème étaient confrontés au désaccord avec les autres développeurs, qui ont écrasé à plusieurs reprises l’idée que le code était mauvais. En 2012, un développeur a déclaré que le code était vulnérable. Deux ans plus tard, un autre développeur a soulevé la même préoccupation concernant la vulnérabilité, mais un autre développeur a déclaré que le code était sûr, après l’avoir testé. En 2018, quelqu’un a à nouveau commenté la vulnérabilité, et un autre développeur a insisté sur le fait que cette personne ne comprenait pas le problème et que le code était sûr.
Par ailleurs, l’extrait de code a été vu dans une copie papier d’un document créé par la communauté des développeurs de Mozilla en 2015 – et a corrigé sept ans plus tard. Cependant, la version vulnérable a également migré vers Stack Overflow fin 2015. Bien que Snippet ait reçu plusieurs mises à jour, la vulnérabilité n’a pas été corrigée. En fait, l’extrait de code là-bas était encore vulnérable à la publication de la recherche actuelle.
La même chose s’est produite en 2016, note les chercheurs, avec une autre question de débordement de pile (avec plus de 88 000 vues) dans laquelle un développeur soupçonnait le code détenait une vulnérabilité. Cependant, cette personne n’a pas été en mesure de vérifier le problème, de sorte que le code a de nouveau été assumé en toute sécurité.
Les chercheurs soupçonnent que les malentendus sur la gravité de la vulnérabilité sont parce que, lorsque les développeurs testent le code, ils utilisent généralement un navigateur Web ou la commande de Linux. Ceux-ci auraient masqué le problème. Les attaquants, notent les chercheurs, ne sont pas tenus d’utiliser des clients standard.
De façon inquiétante, les chercheurs ajoutent: «Nous avons également trouvé plusieurs cours Node.js qui ont utilisé cet extrait de code vulnérable à des fins d’enseignement.» .
