Problèmes causés par les rapports de vulnérabilités générés par l'IA

Daniel Stenberg, auteur de l'outil pour envoyer et recevoir des données sur le réseau, curl, a critiqué l'utilisation des outils d'IA pour la création de rapports sur les vulnérabilités. De tels rapports contiennent des informations détaillées, rédigées dans un langage clair et semblent de qualité, mais sans une analyse approfondie, ils peuvent en réalité induire en erreur, remplaçant les véritables problèmes par un contenu de qualité visuellement attrayante mais sans substance.

Le projet Curl offre des récompenses pour la découverte de nouvelles vulnérabilités et a déjà reçu 415 rapports concernant des problèmes potentiels, dont seulement 64 ont été confirmés comme des vulnérabilités, et 77 comme des erreurs non liées à la sécurité. Ainsi, 66 % de tous les rapports ne contenaient aucune information utile et n'ont fait perdre aux développeurs un temps précieux qui aurait pu être consacré à des tâches plus productives.

Les développeurs sont contraints de perdre beaucoup de temps à analyser des rapports inutiles et à vérifier les informations qui y sont fournies plusieurs fois, car la qualité externe de la présentation suscite une confiance supplémentaire dans les informations et donne l'impression que le développeur a mal compris quelque chose. D'autre part, la rédaction d'un tel rapport exige un minimum d'efforts de la part du déclarant, qui ne prend pas la peine de vérifier l'existence d'un véritable problème, mais se contente de copier aveuglément des données obtenues par des assistants IA, espérant avoir de la chance dans la quête d'une récompense.

Deux exemples de ce type de rapports inutiles sont fournis. Un jour avant la divulgation prévue d'une vulnérabilité critique d'octobre (CVE-2023-38545), un rapport a été soumis via Hackerone disant que le correctif avait été rendu public. En réalité, le rapport contenait un mélange composé par l'assistant IA Google Bard de faits sur des problèmes similaires et d'extraits d'informations détaillées sur des vulnérabilités passées. Au final, l'information semblait nouvelle et pertinente, mais n'avait aucun lien avec la réalité.

Le deuxième exemple concerne le message de débordement de tampon reçu le 28 décembre dans le gestionnaire WebSocket, envoyé par un utilisateur ayant déjà signalé des vulnérabilités à divers projets via Hackerone. Le rapport indiquait une méthode pour reproduire le problème, mentionnant des termes généraux sur l'envoi d'une requête modifiée avec une valeur dépassant la taille du tampon utilisée lors de la copie avec strcpy. L'exemple comprenait également une correction (remplacement de strcpy par strncpy) et renvoyait à la ligne de code « strcpy(keyval, randstr) », dans laquelle, selon le demandeur, une erreur était présente.

Le développeur a vérifié trois fois et n'a trouvé aucun problème, mais étant donné que le rapport était rédigé de manière convaincante et contenait même une correction, il a eu l'impression qu'il manquait quelque chose. La tentative de clarifier comment le chercheur avait réussi à contourner la vérification de taille explicite présente avant l'appel à strcpy et comment la taille du tampon keyval était inférieure à la taille des données lues a abouti à des explications détaillées mais n'apportant aucune information complémentaire, qui ne recrachaient que des raisons évidentes de débordement de tampon, sans lien avec le code spécifique de Curl. Les réponses ressemblaient à une interaction avec un assistant AI et après avoir dépensé une demi-journée en tentatives infructueuses pour comprendre comment le problème se manifestait précisément, le développeur était finalement convaincu qu'il n'y avait en réalité aucune vulnérabilité.

Source : opennet.ru