Daniel Stenberg, auteur d'un utilitaire permettant de recevoir et d'envoyer des données sur le réseau curl, a critiqué l'utilisation d'outils d'IA lors de la création de rapports de vulnérabilité. De tels rapports incluent des informations détaillées, sont rédigés dans un langage normal et semblent de haute qualité, mais sans analyse réfléchie, en réalité, ils ne peuvent qu'induire en erreur, remplaçant les problèmes réels par un contenu poubelle d'apparence de qualité.
Le projet Curl récompense l'identification de nouvelles vulnérabilités et a déjà reçu 415 rapports de problèmes potentiels, dont seulement 64 ont été confirmés comme des vulnérabilités et 77 comme des bogues non liés à la sécurité. Ainsi, 66 % de tous les rapports ne contenaient aucune information utile et ne faisaient qu'enlever aux développeurs du temps qui aurait pu être consacré à quelque chose d'utile.
Les développeurs sont obligés de perdre beaucoup de temps à analyser des rapports inutiles et à revérifier plusieurs fois les informations qu'ils contiennent, car la qualité externe de la conception crée une confiance supplémentaire dans les informations et on a le sentiment que le développeur a mal compris quelque chose. D'un autre côté, générer un tel rapport nécessite un effort minimal de la part du candidat, qui ne prend pas la peine de vérifier un problème réel, mais copie simplement aveuglément les données reçues des assistants IA, espérant avoir de la chance dans la lutte pour recevoir une récompense.
Deux exemples de tels rapports de déchets sont donnés. La veille de la divulgation prévue d'informations sur la dangereuse vulnérabilité d'octobre (CVE-2023-38545), un rapport a été envoyé via Hackerone indiquant que le correctif contenant le correctif était devenu public. En fait, le rapport contenait un mélange de faits sur des problèmes similaires et d'extraits d'informations détaillées sur les vulnérabilités passées compilées par l'assistant IA de Google, Bard. En conséquence, les informations semblaient nouvelles et pertinentes et n’avaient aucun lien avec la réalité.
Le deuxième exemple concerne un message reçu le 28 décembre concernant un débordement de tampon dans le gestionnaire WebSocket, envoyé par un utilisateur qui avait déjà informé divers projets de vulnérabilités via Hackerone. Pour reproduire le problème, le rapport incluait des mots généraux sur la transmission 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 correction (un exemple de remplacement de strcpy par strncpy) et indiquait un lien vers la ligne de code « strcpy(keyval, randstr) » qui, selon le requérant, contenait une erreur.
Le développeur a tout vérifié trois fois et n'a trouvé aucun problème, mais comme le rapport a été rédigé en toute confiance et contenait même une correction, on avait le sentiment qu'il manquait quelque chose quelque part. Une tentative de clarifier comment le chercheur a réussi à contourner la vérification explicite de la taille présente avant l'appel strcpy et comment la taille du tampon keyval s'est avérée inférieure à la taille des données lues a conduit à des explications détaillées, mais ne contenant pas d'informations supplémentaires. qui ne faisait que mâcher les causes courantes évidentes de débordement de tampon non liées au code Curl spécifique. Les réponses faisaient penser à une communication avec un assistant IA, et après avoir passé une demi-journée à tenter inutilement de découvrir exactement comment le problème se manifeste, le développeur a finalement été convaincu qu'il n'y avait en fait aucune vulnérabilité.
Source: opennet.ru