Daniel Stenberg, forfatteren af værktøjet til at hente og sende data over nettet, curl, har kritiseret brugen af AI-værktøjer til at udarbejde rapporter om sårbarheder. Sådanne rapporter indeholder detaljerede oplysninger, skrevet i et almindeligt sprog, og ser ud til at være af høj kvalitet, men uden en grundig analyse kan de faktisk kun føre til misforståelser og erstatte reelle problemer med kvalitetsmæssigt skrammelindhold.
Curl-projektet udbetaler belønninger for at identificere nye sårbarheder og har allerede modtaget 415 rapporter om potentielle problemer, hvoraf kun 64 blev bekræftet som sårbarheder, og 77 som ikke-sikkerhedsrelaterede fejl. Dermed indeholdt 66 % af alle rapporter ingen nyttige oplysninger og tog kun udviklernes tid, som kunne være brugt på noget nyttigt.
Udviklerne er nødt til at spilde meget tid på at gennemgå ubrugelige rapporter og kontrollere de angivne oplysninger flere gange, da det eksterne kvalitetsniveau giver en ekstra tillid til informationen og skaber en følelse af, at udvikleren har misforstået noget. På den anden side kræver udarbejdelsen af en sådan rapport minimale anstrengelser fra indsenderen, som ikke besvimer sig for at kontrollere, om der virkelig er et problem, men blindt kopierer data fra AI-assistenter og håber på held i kampen om at modtage en belønning.
Der gives to eksempler på sådanne skrammelrapporter. Dagen før den planlagte offentliggørelse af oplysninger om den farlige sårbarhed i oktober (CVE-2023-38545) blev der sendt en rapport via Hackerone om, at patchen med rettelsen var blevet offentliggjort. I virkeligheden indeholdt rapporten en sammensat blanding af fakta om lignende problemer og uddrag af detaljerede oplysninger om tidligere sårbarheder, genereret af AI-assistenten Google Bard. Resultatet var, at informationen så ny og aktuel ud, men ikke havde forbindelse til virkeligheden.
Det andet eksempel omhandler en meddelelse, der blev modtaget den 28. december om en bufferoverløbsfejl i WebSocket-håndtereren, sendt af en bruger, der allerede havde informeret forskellige projekter om sårbarheder via Hackerone. Som metode til at reproducere problemet nævnte rapporten generelle ord om at sende en ændret anmodning med en værdi, der oversteg størrelsen på bufferen, der blev brugt ved kopiering med strcpy. Rapporten indeholdt også et eksempel på en rettelse (et eksempel på at erstatte strcpy med strncpy) og angav en henvisning til kodelinjen 'strcpy(keyval, randstr)', hvor ansøgeren mente, der var en fejl.
Udvikleren har tjekket alting tre gange og fandt ikke nogen problemer, men da rapporten var skrevet med selvtillid og endda indeholdt en rettelse, opstod der en følelse af, at der var noget, der blev overset. Forsøg på at afklare, hvordan forskeren lykkedes med at omgå den åbenlyse størrelseskontrol, der forelå før kaldet til strcpy, og hvordan størrelsen på bufferen keyval blev mindre end størrelsen på de læste data, førte til detaljerede, men ikke yderligere informative forklaringer, der kun uddybbede de åbenlyse generelle årsager til bufferoverløb, som ikke var relateret til den specifikke Curl-kode. Svarene mindede om kommunikation med en AI-assistent, og efter at have brugt en halv dag på meningsløse forsøg på at finde ud af, hvordan problemet rent faktisk manifesterer sig, var udvikleren endelig overbevist om, at der ikke var nogen sårbarhed i virkeligheden.
Kilde: opennet.ru
