Daniel Stenberg, forfatter til et værktøj til modtagelse og afsendelse af data over netværkskrøllen, kritiserede brugen af AI-værktøjer, når der oprettes sårbarhedsrapporter. Sådanne rapporter indeholder detaljerede oplysninger, er skrevet på normalt sprog og ser af høj kvalitet ud, men uden gennemtænkte analyser i virkeligheden kan de kun være vildledende og erstatte reelle problemer med affaldsindhold af høj kvalitet.
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-sikkerhedsfejl. Således indeholdt 66 % af alle rapporter ingen brugbar information og tog kun tid fra udviklere, der kunne være brugt på noget nyttigt.
Udviklere er tvunget til at spilde en masse tid på at analysere ubrugelige rapporter og dobbelttjekke oplysningerne der flere gange, da den eksterne kvalitet af designet skaber yderligere tillid til informationen, og der er en følelse af, at udvikleren har misforstået noget. På den anden side kræver det minimal indsats af ansøgeren at generere en sådan rapport, som ikke gider at tjekke for et reelt problem, men blot blindt kopierer data modtaget fra AI-assistenter i håb om held i kampen for at modtage en belønning.
Der gives to eksempler på sådanne affaldsrapporter. Dagen før den planlagte offentliggørelse af information om den farlige oktober-sårbarhed (CVE-2023-38545) blev der sendt en rapport via Hackerone om, at patchen med rettelsen var blevet offentligt tilgængelig. Faktisk indeholdt rapporten en blanding af fakta om lignende problemer og uddrag af detaljerede oplysninger om tidligere sårbarheder udarbejdet af Googles AI-assistent Bard. Som et resultat så informationen ny og relevant ud og havde ingen forbindelse med virkeligheden.
Det andet eksempel vedrører en besked modtaget den 28. december om et bufferoverløb i WebSocket-handleren, sendt af en bruger, der allerede havde informeret forskellige projekter om sårbarheder gennem Hackerone. Som en metode til at reproducere problemet indeholdt rapporten generelle ord om at sende en ændret anmodning med en værdi større end 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 indeholdt et link til kodelinjen "strcpy(keyval, randstr)", som ifølge sagsøgeren indeholdt en fejl.
Udvikleren dobbelttjekkede alt tre gange og fandt ingen problemer, men da rapporten var skrevet sikkert og endda indeholdt en rettelse, var der en følelse af, at der manglede noget et sted. Et forsøg på at afklare, hvordan forskeren formåede at omgå den eksplicitte størrelseskontrol, der var til stede før strcpy-opkaldet, og hvordan størrelsen af keyval-bufferen viste sig at være mindre end størrelsen af de læste data, førte til detaljerede, men uden yderligere oplysninger, forklaringer der kun tyggede på de åbenlyse almindelige årsager til bufferoverløb, der ikke var relateret til specifik Curl-kode. Svarene mindede om at kommunikere med en AI-assistent, og efter at have brugt en halv dag på meningsløse forsøg på at finde ud af præcis, hvordan problemet manifesterer sig, blev udvikleren endelig overbevist om, at der faktisk ikke var nogen sårbarhed.
Kilde: opennet.ru