Daniel Stenberg, auteur de l'utilitaire curl pour l'envoi et la réception de données réseau, a critiqué l'utilisation des outils d'IA dans les rapports de vulnérabilités. Ces rapports contiennent des informations détaillées, sont rédigés dans un langage clair et semblent de haute qualité, mais sans analyse approfondie, ils peuvent en réalité induire en erreur, en remplaçant les véritables problèmes par un contenu de qualité, certes, mais superflu.
Le projet Curl offre des primes pour l'identification de nouvelles vulnérabilités et a déjà reçu 415 signalements de problèmes potentiels, dont seulement 64 ont été confirmés comme étant des vulnérabilités et 77 comme étant des problèmes non liés à la sécurité. Ainsi, 66 % des signalements étaient inutiles et ont simplement fait perdre du temps aux développeurs, temps qui aurait pu être consacré à des tâches plus productives.
Les développeurs perdent un temps précieux à analyser des rapports inutiles et à revérifier les informations à plusieurs reprises, car la qualité visuelle de la présentation leur confère une crédibilité illusoire, laissant croire à une erreur d'interprétation. Par ailleurs, la génération d'un tel rapport ne demande que peu d'efforts à son auteur, qui ne se soucie guère de vérifier l'existence d'un problème réel, mais se contente de copier aveuglément les données fournies par les assistants IA, espérant ainsi remporter une récompense.
Deux exemples de tels rapports erronés sont présentés. La veille de la publication, prévue en octobre, d'informations concernant une vulnérabilité critique (CVE-2023-38545), un rapport a été soumis via HackerOne, affirmant qu'un correctif était désormais accessible au public. En réalité, ce rapport contenait un mélange d'informations sur des problèmes similaires et d'extraits détaillés sur d'anciennes vulnérabilités, compilés par l'assistant IA Bard de Google. Les informations ainsi obtenues semblaient nouvelles et pertinentes, mais étaient totalement déconnectées de la réalité.
Le second exemple concerne un signalement de dépassement de tampon dans un gestionnaire WebSocket, reçu le 28 décembre. Ce signalement a été effectué par un utilisateur ayant déjà signalé des vulnérabilités à divers projets via HackerOne. Le rapport décrivait une méthode pour reproduire le problème, en utilisant des termes généraux pour décrire l'envoi d'une requête modifiée avec une valeur supérieure à la taille du tampon utilisé lors de la copie avec `strcpy`. Le rapport fournissait également un exemple de solution (remplacement de `strcpy` par `strncpy`) et un lien vers la ligne de code « strcpy(keyval, randstr) » que l'auteur du signalement estimait être à l'origine de l'erreur.
Le développeur a tout vérifié trois fois sans trouver d'anomalie. Cependant, le rapport, rédigé avec assurance et proposant même une solution, lui a laissé un goût amer. Toute tentative pour comprendre comment le chercheur avait contourné la vérification de taille explicite précédant l'appel à `strcpy` et comment la taille du tampon `keyval` était inférieure aux données lues a abouti à des explications détaillées, mais peu pertinentes, se contentant de ressasser des causes générales et évidentes de dépassements de tampon, sans lien avec le code Curl spécifique. Ces réponses ressemblaient à une conversation avec un assistant vocal. Après avoir passé une demi-journée à tenter vainement de comprendre l'origine du problème, le développeur s'est finalement convaincu de l'absence de vulnérabilité.
Source: opennet.ru
