Le rapport de sécurité curl généré par l’IA

• Le projet curl gère un bug bounty et, avec la hausse des rapports de sécurité qui semblent générés par des LLM, le temps des développeurs est désormais absorbé par la vérification de faux signalements plutôt que par la correction de véritables vulnérabilités
• Jusqu’à présent, curl a versé plus de 70 000 dollars et reçu 415 rapports, mais seuls 64 correspondaient à de réels problèmes de sécurité, tandis que 77 ont été classés comme informatifs
• Le cœur du problème est que ces rapports disposent d’un anglais convaincant, de détails techniques et même de correctifs proposés, ce qui augmente fortement le coût de revue
• En 2023, un signalement a affirmé que des modifications de code liées à CVE-2023-38545 avaient été divulguées, et un autre a évoqué un dépassement de tampon dans WebSocket, mais il n’y avait en réalité ni divulgation ni buffer overflow
• L’IA peut être utile pour la traduction, l’aide à la rédaction ou comme outil de détection de vulnérabilités, mais soumettre des sorties de LLM sans validation humaine reporte sur les projets open source le coût de la réponse en matière de sécurité

---

Les rapports de faible qualité auxquels le bug bounty de curl est confronté

• Le projet curl exploite un bug bounty qui verse de véritables récompenses aux hackers signalant des problèmes de sécurité
• La perspective d’une récompense attire des « luck seekers » qui se contentent de faire des grep de motifs dans le code source ou de lancer des scanners de sécurité basiques, puis soumettent les résultats sans analyse suffisante
• Par le passé, les rapports de faible qualité pouvaient généralement être identifiés et écartés rapidement, sans que la perte de temps ne devienne un problème majeur pour le projet
• Résultats du bug bounty curl à ce jour :
  • plus de 70 000 dollars de récompenses versés
  • 415 rapports de vulnérabilité reçus
  • 64 cas confirmés comme de véritables problèmes de sécurité
  • 77 cas classés comme informatifs, correspondant par exemple à des bugs ordinaires
  • 66 % de l’ensemble des rapports n’étaient ni des problèmes de sécurité ni des bugs ordinaires

Pourquoi les faux rapports crédibles sont plus dangereux

• Plus un faux rapport est sophistiqué, plus il faut de temps d’enquête et d’énergie avant de pouvoir l’écarter
• Tous les rapports de sécurité doivent être lus par des humains afin d’en évaluer la portée réelle
• Le travail sur la sécurité est facilement traité comme prioritaire, si bien que même les faux rapports peuvent repousser d’autres travaux de développement
• Les rapports qui n’améliorent en rien la sécurité prennent du temps qui pourrait être consacré à corriger des bugs pénibles ou à développer de nouvelles fonctionnalités
• La gestion répétée de rapports de faible qualité accroît aussi l’épuisement énergétique des développeurs

Des rapports de sécurité qui semblent produits par l’IA

• L’IA est un outil généraliste, qui peut servir à de bonnes fins mais aussi être utilisée de mauvaises façons
• Elle pourrait être employée de manière productive pour détecter et signaler des problèmes de sécurité, mais le projet curl n’a pas encore trouvé de bon exemple en ce sens
• Pour l’instant, le schéma observé consiste à mettre du code curl dans un LLM, puis à soumettre sa sortie comme rapport de vulnérabilité
• Comme les utilisateurs ne collent pas toujours simplement la sortie de l’IA et y mêlent aussi leurs propres phrases, la détection devient plus difficile
• Même si l’ensemble du rapport ne correspond pas exactement au texte produit par l’IA, le résultat peut malgré tout être un rapport invalide

Pourquoi il est difficile de rejeter un rapport sur la seule base de traces d’IA

• Certains rapporteurs ne maîtrisent pas bien l’anglais, si bien qu’il faut parfois plusieurs échanges de questions-réponses pour comprendre leur intention
• Les barrières de langue et de culture existent réellement, et ce processus de communication peut être considéré comme naturel
• Certains rapporteurs utilisent l’IA ou d’autres outils comme aide à la traduction et à la rédaction afin de mieux communiquer dans une langue étrangère
• Un rapporteur qui ne parle pas bien anglais peut malgré tout découvrir et signaler un véritable problème de sécurité
• Il est donc difficile de rejeter immédiatement un signalement au seul motif que certaines parties du texte portent des traces de génération par IA, et les faux rapports bien rédigés prennent plus de temps à trancher

Cas A : affirmation de divulgation des modifications de code de CVE-2023-38545

• À l’automne 2023, la communauté curl a été informée de la publication imminente de CVE-2023-38545, évaluée avec une sévérité high
• La veille de la divulgation de ce problème, un rapport intitulé “Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet” a été soumis sur HackerOne
• Rien qu’au titre, l’affaire aurait pu être très grave si elle avait été réelle
• Mais le rapport ressemblait à une hallucination typique de l’IA, mélangeant faits et détails d’anciens incidents de sécurité pour produire un nouveau contenu sans rapport avec la réalité
• Les modifications liées à CVE-2023-38545 n’avaient pas été divulguées sur Internet, et les modifications effectivement publiques concernaient, comme prévu, un ancien problème distinct
• Le rapporteur a indiqué avoir trouvé ce problème avec Bard, ce qui a facilité l’identification de l’erreur et la clôture du rapport

Cas B : allégation de buffer overflow dans WebSocket

• Le matin du 28 décembre 2023, un rapport intitulé “Buffer Overflow Vulnerability in WebSocket Handling” a été soumis sur HackerOne
• À première vue, le titre semblait sérieux, mais le code WebSocket de curl relevait encore d’une fonctionnalité expérimentale et n’entrait donc pas dans le périmètre du bug bounty
• Le rapporteur était un utilisateur inconnu, mais il avait une réputation correcte sur HackerOne et il ne s’agissait pas de son premier rapport de sécurité
• Le rapport était bien structuré, avec des détails, un anglais correct et même un correctif proposé
• Au départ, il paraissait meilleur qu’un premier rapport moyen, et donnait l’impression que son auteur comprenait le problème et proposait une solution
• Dix-neuf minutes plus tard, après plusieurs vérifications du code, il restait impossible de trouver le buffer overflow allégué
• Après des questions répétées et plusieurs réponses aux accents hallucinatoires, il a été conclu qu’il ne s’agissait pas d’un vrai problème, et le dossier a été fermé comme not applicable le même après-midi
• Il n’est pas certain que ces réponses aient été générées par un LLM, mais plusieurs indices allaient dans ce sens

Fonction de blocage sur HackerOne et sanctions de réputation

• Au départ, il a été pensé que HackerOne ne proposait pas de fonction permettant de bloquer explicitement un rapporteur pour empêcher toute communication supplémentaire avec le projet
• Il est indiqué que cette fonction aurait été utilisée si elle avait existé
• Lorsqu’un signalement est fermé comme not applicable, la réputation du chercheur sur HackerOne baisse, mais si cela ne se produit qu’une seule fois sur un seul projet, l’effet dissuasif reste très faible
• Une mise à jour ultérieure ajoute que cette fonction existe en réalité, mais qu’elle n’avait pas été cherchée au bon endroit

Davantage de rapports générés par LLM à l’avenir

• Ce type de rapport devrait devenir plus courant avec le temps
• Les projets pourront mieux détecter les signaux indiquant une génération par IA et apprendre à rejeter des rapports sur cette base
• Cela pourrait toutefois pénaliser aussi les cas où l’IA a été utilisée de façon appropriée, par exemple pour aider à traduire ou à formuler un texte
• À l’avenir, certains outils utilisant l’IA pour trouver des problèmes de sécurité pourraient réellement mieux fonctionner
• Même un niveau très faible de validation humaine pourrait considérablement améliorer l’utilité et les résultats de ce type d’outils
• La recherche de raccourcis pour obtenir rapidement une récompense a de fortes chances de continuer, et l’accès facile à des LLM puissants devrait entraîner l’arrivée de davantage de rapports de faible qualité dans la boîte de réception HackerOne

[GN⁺]

Avis sur Hacker News

• Des phrases comme « Bien sûr ! Je vais expliquer plus en détail les préoccupations soulevées par le responsable du tri » relèvent typiquement du style LLM, et donnent l’impression d’un majordome robotique.
  Je n’ai presque jamais vu de vraies personnes écrire comme ça, et le fait de parler du « responsable du tri » à la troisième personne est aussi étrange, comme s’il y avait une autre entité qui orientait la réponse.
  Le fait que les LLM aient un ton distinctif identifiable ne me dérange pas, mais ce qui m’inquiète, ce n’est pas que les LLM parlent comme des humains : c’est que les humains commencent à parler comme des LLM.

  • Daniel Stenberg[1] a mis le doigt sur un bon point : curl est utilisé dans le monde entier, donc il n’y a rien d’étrange à ce qu’une personne dont l’anglais n’est pas la langue maternelle se fasse aider par un LLM pour rédiger un rapport de bug.
    Par conséquent, on ne peut pas conclure que le contenu même du rapport a été fabriqué par un LLM sur la seule base d’indices superficiels donnant l’impression que l’anglais a été généré par un LLM.

    [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

  • J’aimerais bien que quelqu’un soit en train d’écrire quelque part une SF dystopique où nos seigneurs robots s’excusent sans cesse en disant des choses comme « En fin de compte, le fait de vous rendre dépend de vos besoins et préférences spécifiques ».

  • En lisant « on dirait un majordome robotique », j’ai soudain compris l’expression Butlerian Jihad.

  • En Inde, l’anglais est parfois enseigné dans une variante britannique héritée de l’époque coloniale et destinée à la classe des domestiques, une sorte d’anglais « de majordome ».
    Si vous n’avez jamais vu ce ton jusqu’ici, c’est probablement que vous n’avez jamais eu affaire au support technique entreprise de Microsoft.

  • C’est clairement un gros signal d’alerte, mais si une vraie personne avait transmis ce contenu lamentable, il aurait suffi de supprimer cette seule ligne.
    Le contenu resterait suspect, mais il y aurait beaucoup moins d’indices pour s’en rendre compte.

• Les gens qui visent des « primes à la mendicité » ont déjà rendu l’exploitation des programmes de bug bounty assez pénible.
  À l’époque, il fallait qu’une vraie personne consacre du temps à produire un « rapport de bug » qui ne valait pratiquement rien, mais avec les LLM, on peut créer des faux rapports pour un coût quasi nul, et cela pourrait vraiment devenir incontrôlable.
  Personnellement, je pense que cela pourrait marquer la fin des programmes de bug bounty.
  Ou alors il faudra peut-être les verrouiller davantage : recevoir des candidatures au programme, vérifier à faible coût qu’il s’agit bien de vraies personnes, de véritables chercheurs en sécurité et de gens qui cherchent à trouver des bugs de sécurité ayant un impact, puis réserver la soumission de bugs et les récompenses financières aux seules personnes approuvées.

  • Il existe déjà des plateformes qui proposent ce genre de fonctionnalités.
    Elles gèrent des chercheurs connus dans un pool, suivent leur statut et permettent d’ajuster le degré d’ouverture publique d’un programme.
    Certaines mettent aussi en place des responsables du tri, mais le succès dépend beaucoup du caractère plus ou moins typique du projet.
  • Une autre solution pourrait être d’instaurer des frais de soumission.
    Je ne sais pas si cela aiderait, mais ce pourrait être un moyen de dissuasion contre les soumissions massives de déchets générés par des machines.
    Le pire scénario serait une avalanche de déchets IA, puis, pour « résoudre » le problème, l’introduction d’un filtrage IA tout aussi mauvais, ce qui ferait baisser la qualité globale pour tous ceux qui essaient de participer de bonne foi.

• Au début, j’ai cru que cet article était un doublon de https://news.ycombinator.com/item?id=37904047, mais il s’est avéré qu’il s’agissait d’un autre faux rapport de vulnérabilité généré par LLM soumis contre curl sur HackerOne.

  • Heureusement, je ne devenais pas fou.
    En lisant, j’avais vraiment l’impression d’avoir déjà vu ça, et c’est presque étrange tant cela ressemble à l’incident précédent.
    Est-ce que les projets populaires comme Curl vont continuer à recevoir des signalements d’incidents écrits par LLM de gens qui veulent ajouter une ligne à leur CV ?
  • Les clients de HackerOne sont les entreprises qui exploitent des programmes de bug bounty.
    Ils devraient sans doute gérer avec un peu plus de prudence les personnes autorisées à envoyer à leurs clients du spam de déchets LLM visant seulement la visibilité.
  • Je n’avais aucune idée que cela s’était déjà produit.
    Dans ce cas, cette affaire constitue un précédent encore plus clair.

• Ce qui m’inquiète le plus, c’est que quelques centimes de coût LLM ont fait perdre beaucoup de temps d’ingénierie coûteux et important.
  Quand on imagine tous les efforts qu’il faudra consacrer à démonter toutes les fausses informations produites en ce moment, cela ressemble à la loi de Brandolini.

  • Oui, les LLM ont le potentiel de gâcher une énorme partie d’Internet, et je ne sais pas vraiment si c’est un problème soluble.
    Les modèles actuels laissent des indices visibles, mais les modèles futurs seront différents et meilleurs.
    La détection et le blocage deviendront une course aux armements, au point que beaucoup de personnes et de plateformes productives pourraient avoir du mal à suivre.

• Il est intéressant de constater que nous avons transformé l’écriture, qui était le moyen à plus faible bande passante de prouver une action et un effort, en quelque chose qui demande bien plus de travail pour déterminer si une action ou un effort a réellement existé.
  Les effets en cascade seront probablement très importants.
  Ici, le rapporteur comme les mainteneurs ont perdu du temps qu’ils auraient pu consacrer à des tâches plus utiles, et l’ensemble du processus des bug bounties et des CVE fondés sur le crowdsourcing est détérioré par la baisse du rapport signal/bruit.
  Il en résultera probablement une hausse des barrières à la soumission pour lutter contre le spam, ce qui pourrait conduire à moins de bugs découverts et corrigés, davantage de vulnérabilités de sécurité, et tous les problèmes qui en découlent.
  La même dynamique s’applique à d’autres domaines, au point que l’on pourra de moins en moins accorder sa confiance aux avis produits, aux documents déposés devant les tribunaux, aux recettes, aux guides pratiques, aux conseils médicaux, etc.
  L’une des promesses d’Internet était l’expansion rapide des contenus grâce à la démocratisation de la publication, mais on a l’impression d’assister à l’évidement même des avantages qui subsistaient.

• Il est particulièrement étrange de mettre en cause ici le contrôle des limites de longueur.
  Aucune donnée fournie par l’utilisateur n’est utilisée, et toutes les tailles sont statiques au moment de la compilation.
  curl place dans un tampon statique de 40 octets une chaîne aléatoire de 16 octets encodée en base64, soit 25 octets ASCII plus le caractère de fin de chaîne nul \0.

  https://github.com/curl/curl/blob/1d8e8c9ad1ff3351386422535f...

Et par pure curiosité, quelqu’un qui connaît mieux le C que moi pourrait-il expliquer pourquoi on utilise ici la variable locale keyval ?
Pourquoi ne pas simplement définir heads[3].val = randstr, puis appeler free() une fois le traitement des données d’en-tête terminé ?
Et pourquoi keyval fait-il 40 octets, et non 26 ou 32 ?

• L’intention est probablement de réduire le nombre d’endroits où il faut appeler free, et donc le risque de l’oublier.
  On pourrait se demander si cela peut déjà arriver à la ligne 580, mais en pratique ce cas ne se produit peut-être jamais.

• Dans ce cas, autant supprimer à la fois randstr et keyval et encoder directement dans &heads[3].val, puisqu’il y a de toute façon une allocation.
  Il faut tout de même passer l’inutile randlen, sinon ça plante.
  Toute la beauté des paramètres de sortie en C.
  Cette danse qui consiste à « copier depuis le tas vers une variable de pile » ne réduit pas non plus le nettoyage à faire,
  puisqu’après l’encodage il n’y a de toute façon qu’un seul retour possible.
  Cela dit, si l’on a d’abord « posé » les variables nécessaires plus haut, puis réalisé ensuite que Curl_base64_encode alloue toujours, on comprend comment le code actuel a pu apparaître.

• Utiliser la pile est presque gratuit, car l’espace est déjà réservé lors de la mise en place de la fonction et il est nettoyé automatiquement au retour de la fonction.
  Utiliser le tas demande plus de travail, peut échouer et nécessite un nettoyage manuel.

• L’une des leçons importantes que j’ai apprises au lycée était de savoir distinguer un mensonge élégamment formulé d’une vérité maladroitement exprimée.
  Mais cela peut être difficile.
  Les gens ont tendance à utiliser la grammaire et le style corrects comme premier filtre du discours intellectuel, et reproduire de façon crédible la forme du langage est quelque chose que les LLM font extrêmement bien.

  • Je me demande à quel point cette leçon a marqué cette personne et ses camarades à l’époque.
    C’est un problème très délicat, et je pense que la plupart des adultes ne sont pas prêts à le traiter.
    Une personne moyenne est tout à fait capable de distinguer les deux, mais le problème est qu’il faut prendre l’habitude de lire les textes de manière systématique et y consacrer des efforts.
    C’est très difficile à faire quand on fait défiler son téléphone tard le soir.

• S’il n’y avait pas eu l’agacement et la perte de temps, la situation où dineshsec / dinesh_b a essayé d’apprendre à Daniel comment utiliser strncpy aurait été drôle.
  Il a d’abord tagué Daniel avec un identifiant arbitraire, puis a inventé du code qui n’existait pas en disant : « le code problématique est le suivant : »

  • C’est un problème typique de mauvaise utilisation des LLM.
    L’utilisateur veut analyser quelque chose, mais c’est trop long, alors il le découpe en plusieurs requêtes.
    Puis, au moment d’arriver au point essentiel, l’extrait de code d’origine a disparu du contexte, et le modèle produit avec assurance quelque chose qui n’existe pas en réalité mais qui paraît plausible.

• Il ne faut pas utiliser strcpy ni strncpy, mais simplement memcpy.
  strncpy, en particulier, est clairement le pire choix des trois.
  Le code connaît déjà la taille du tampon source et a déjà vérifié que cela tient dans le tampon destination ; il n’y a donc aucune raison d’appeler strcpy pour mesurer inutilement la longueur de la chaîne.
  Franchement, la recommandation du LLM est du genre à déconseiller activement.
  Si l’on ne connaît pas la taille, qu’on ne se soucie pas d’une troncature silencieuse et qu’on ne se soucie pas non plus des performances, on peut utiliser snprintf.
  strncpy remplit inutilement de zéros le reste du tampon.
  À moins de manipuler quelque chose comme une UI, il faut généralement se soucier de la troncature, et dans ce cas strncpy ne vous sauvera pas.

• Cela semble lié : https://news.ycombinator.com/item?id=38840907