La société Anthropic a annoncé une extension des capacités du modèle AI Claude Opus 4.6 pour la recherche de vulnérabilités dans le code et a partagé les résultats d'une expérience ayant révélé plus de 500 vulnérabilités inconnues (0-day) dans les dernières versions de divers projets open source. Le travail s'est concentré sur la recherche de vulnérabilités causées par des problèmes de gestion de la mémoire, car leur présence est plus facile à vérifier. Chaque vulnérabilité a été classée comme ayant un niveau élevé de dangerosité. Chaque vulnérabilité a été vérifiée manuellement et confirmée par des employés d'Anthropic ou des chercheurs en sécurité externes.
Pour l'analyse des vulnérabilités, des bases de code de projets open source populaires, qui subissent depuis longtemps des tests de fuzzing continus via le service OSS-Fuzz, ont été utilisées. Contrairement au fuzzing, qui génère un flux de combinaisons aléatoires de données d'entrée, le modèle AI tentait d'analyser le code en tenant compte des corrections passées pour identifier des erreurs non résolues similaires, en mettant en évidence des motifs problématiques et en déduisant logiquement quelles données d'entrée pourraient perturber le flux d'exécution.
Les informations sur les vulnérabilités identifiées lors de l'expérience commencent déjà à être transmises aux mainteneurs, avec lesquels un travail conjoint est en cours pour accepter les correctifs. Pour aider les mainteneurs, des correctifs ont été développés manuellement pour résoudre les problèmes identifiés lors de la vérification. À titre d'exemple, trois vulnérabilités dans GhostScript, OpenSC et CGIF, qui à la date de publication ont été corrigées par les mainteneurs.
La configuration utilisée pour identifier les problèmes n'était pas ressemblante aux systèmes traditionnels de recherche automatique de vulnérabilités — le modèle Claude Opus 4.6 a eu accès à une machine virtuelle, où, en plus du code examiné, des outils de développement standard (coreutils, Python, etc.) et des utilitaires pour le débogage et l'analyse des vulnérabilités (y compris des outils de fuzzing) étaient installés. Le modèle n'a pas reçu d'instructions claires sur l'utilisation de ces outils et aucune information spéciale sur les méthodes de recherche de vulnérabilités n'a été fournie. Le modèle a seulement été chargé d'une tâche et a eu l'opportunité de réfléchir de manière autonome à l'utilisation optimale des outils disponibles.
Dans sa recherche de vulnérabilités dans GhostScript, le modèle AI a d'abord tenté des tests de fuzzing, mais lorsque cela n'a pas donné de résultats, il est passé à l'analyse de code. L'analyse de code n'ayant pas non plus été concluante, le modèle a commencé à étudier l'historique des modifications dans git et a remarqué, dans l'un des commits, une mention de la vérification des limites de tampon. En examinant le commit, le modèle a déterminé que la correction ajoutait une vérification manquante des limites de tampon lors du traitement des polices.
Ensuite, le modèle a identifié le code qui était présent avant la correction et a tenté de trouver dans le reste du code des modèles d'utilisation similaires de la fonction problématique, restés non corrigés. Enfin, dans le fichier gdevpsfx.c, un appel à la fonction gs_type1_blend a été découvert sans vérification de la validité des valeurs. En fin de compte, le modèle a sélectionné le contenu d'un fichier dont le traitement provoquait un arrêt brutal en raison de l'écriture de données en dehors de la mémoire allouée.
Dans CGIF, le modèle AI s'est basé sur le fait que lors de l'extraction de fichiers GIF, la bibliothèque supposait que la taille des données compressées était toujours inférieure à celle des données extraites. La recherche de vulnérabilités s'est concentrée sur la définition des conditions dans lesquelles les données compressées par l'algorithme LZW seraient plus grandes que celles qui ont été décompressées. Ces conditions ont été trouvées et le modèle AI a pu générer un fichier GIT dont le traitement a conduit à un débordement de tampon. Dans OpenSC, le problème a été identifié après l'analyse de l'utilisation dans le code de fonctions potentiellement dangereuses telles que strrchr et strcat.
Il est noté que les modèles linguistiques ont atteint un niveau leur permettant d'identifier des vulnérabilités auparavant inconnues et qu'ils dépasseront bientôt les experts en sécurité en termes de rapidité et d'échelle de recherche de vulnérabilités. Il est prévu que l'augmentation du nombre de vulnérabilités identifiées nécessitera une réforme des processus d'information établis, car les 90 jours actuellement consacrés à la correction seront insuffisants.
Source : opennet.ru
