Anthropic a annoncé l'amélioration des capacités de détection des vulnérabilités de son modèle d'IA Claude Opus 4.6 et a partagé les résultats d'une expérience ayant permis d'identifier plus de 500 vulnérabilités zero-day (crises de sécurité zéro) jusqu'alors inconnues dans les dernières versions de divers projets open source. L'étude s'est concentrée sur l'identification des vulnérabilités liées à des problèmes de mémoire, car leur présence est plus facile à vérifier. Toutes les vulnérabilités identifiées ont été classées comme critiques. Chaque vulnérabilité a été examinée et confirmée manuellement par des employés d'Anthropic ou des chercheurs en sécurité externes.
Pour analyser les vulnérabilités, nous avons utilisé les bases de code de projets open source populaires, soumis depuis longtemps à des tests de fuzzing continus via le service OSS-Fuzz. Contrairement au fuzzing, qui génère un flux de toutes les combinaisons aléatoires possibles de données d'entrée, le modèle d'IA a analysé le code en tenant compte des correctifs antérieurs afin d'identifier les erreurs non résolues similaires, de mettre en évidence les schémas problématiques et de déduire logiquement quelles données d'entrée pourraient perturber l'exécution.
Les informations relatives aux vulnérabilités identifiées lors de l'expérimentation ont déjà commencé à être partagées avec les responsables de la maintenance, avec lesquels nous collaborons pour approuver les correctifs. Afin de faciliter leur travail lors de l'examen manuel, des correctifs ont été développés pour résoudre les problèmes identifiés. À titre d'exemple, trois vulnérabilités affectant GhostScript, OpenSC et CGIF sont listées ; elles ont été corrigées par les responsables de la maintenance au moment de la publication.
La configuration utilisée pour identifier les problèmes n'était pas similaire aux systèmes traditionnels d'analyse automatisée des vulnérabilités ; le modèle Claude Opus 4.6 a eu accès à machine virtuelleLe modèle, outre le code analysé, comprenait des outils de développement standard (coreutils, Python, etc.) et des utilitaires de débogage et d'analyse de vulnérabilités (dont des outils de fuzzing). Il ne recevait aucune instruction précise sur l'utilisation de ces outils ni aucune information spécifique sur les méthodes de détection des vulnérabilités. Il devait simplement effectuer une tâche et déterminer de manière autonome l'utilisation optimale des outils disponibles.
Lors de la recherche de vulnérabilités dans GhostScript, le modèle d'IA a d'abord tenté des tests de fuzzing, mais face à leur échec, il s'est tourné vers l'analyse du code. Cette dernière ayant également échoué, le modèle a alors examiné l'historique des commits Git et a repéré une mention de vérification des limites du tampon dans l'un d'eux. Après analyse, le modèle a déterminé que le correctif ajoutait une vérification manquante des limites du tampon lors du traitement des polices.
Le modèle a ensuite identifié le code existant avant la correction et a tenté de trouver des schémas d'utilisation similaires de la fonction problématique dans le code restant non corrigé. Finalement, un appel à la fonction gs_type1_blend sans vérification de validation de valeur a été détecté dans le fichier gdevpsfx.c. Enfin, le modèle a identifié le contenu du fichier dont le traitement avait entraîné un plantage dû à l'écriture de données dans une zone mémoire située en dehors du tampon alloué.
Dans CGIF, le modèle d'IA s'appuyait sur le fait que, lors de la décompression de fichiers GIF, la bibliothèque supposait que la taille des données compressées était toujours inférieure à celle des données décompressées. La recherche de vulnérabilités s'est concentrée sur l'identification des conditions dans lesquelles les données compressées LZW seraient plus volumineuses que les données décompressées. De telles conditions ont été trouvées, et le modèle d'IA a pu générer un fichier GIT dont le traitement a provoqué un dépassement de tampon. Dans OpenSC, le problème a été identifié après l'analyse de l'utilisation des fonctions potentiellement dangereuses `strrchr` et `strcat` dans le code.
Il est à noter que les modèles de langage ont atteint un niveau leur permettant d'identifier des vulnérabilités jusqu'alors inconnues et qu'ils surpasseront bientôt les experts en sécurité en termes de rapidité et d'ampleur des recherches de vulnérabilités. On s'attend à ce que le nombre croissant de vulnérabilités identifiées nécessite une refonte des procédures de divulgation existantes, le délai actuel de 90 jours pour la correction des problèmes étant insuffisant.
Source: opennet.ru
