Daniel Stenberg, skaparen av verktyget för att hÀmta och skicka data över nÀtet, curl, har kritiserat anvÀndningen av AI-verktyg nÀr man skapar sÄrbarhetsrapporter. SÄdana rapporter innehÄller detaljerad information, Àr skrivna pÄ ett begripligt sprÄk och ser professionella ut, men utan noggrant analys kan de faktiskt bara leda till missförstÄnd, ersÀtta verkliga problem med kvalitativt utseende skrÀpinnehÄll.
Curl-projektet betalar belöningar för att identifiera nya sÄrbarheter och har redan fÄtt 415 rapporter om potentiella problem, av vilka endast 64 bekrÀftades som sÄrbarheter, och 77 som icke-sÀkerhetsrelaterade fel. DÀrmed innehöll 66 % av alla rapporter inga anvÀndbara uppgifter och tog bara tid frÄn utvecklarna som kunde ha anvÀnts bÀttre.
Utvecklarna tvingas slösa mycket tid pÄ att gÄ igenom meningslösa rapporter och verifiera de angivna uppgifterna flera gÄnger, eftersom den externa kvalitén pÄ presentationen ger ett extra förtroende för informationen och skapar en kÀnsla av att utvecklaren har missförstÄtt nÄgot. à andra sidan krÀver skapandet av en sÄdan rapport minimala anstrÀngningar frÄn anmÀlare, som inte besvÀrar sig med att kontrollera förekomsten av ett verkligt problem, utan bara blint kopierar data frÄn AI-assistenter, i hopp om tur i kampen om att fÄ belöningen.
TvÄ exempel pÄ sÄdana skrÀprapporter ges. Dagen före det planerade avslöjandet av information om en oktoberrelaterad sÄrbarhet (CVE-2023-38545) skickades en rapport via Hackerone som pÄstod att fixet hade blivit offentligt. I sjÀlva verket innehöll rapporten en AI-genererad blandning av fakta om liknande problem och utdrag frÄn detaljerade upplysningar om tidigare sÄrbarheter. Resultatet var att informationen verkade ny och relevant, men hade inget att göra med verkligheten.
Det andra exemplet handlar om det meddelande som mottogs den 28 december angÄende buffertöverskridning i WebSocket-hanteraren, skickat av en anvÀndare som redan informerat olika projekt om sÄrbarheter via Hackerone. Som metod för att Äterskapa problemet angavs allmÀnna ord om att skicka en modifierad begÀran med ett vÀrde som överstiger buffertens storlek som anvÀnds vid kopiering med hjÀlp av strcpy. Rapporten gav ocksÄ ett exempel pÄ en lösning (exempel pÄ att ersÀtta strcpy med strncpy) och en lÀnk till koden "strcpy(keyval, randstr)", dÀr klaganden ansÄg att det fanns ett fel.
Utvecklaren kontrollerade allt tre gÄnger men hittade inga problem. Eftersom rapporten skrevs pÄ ett övertygande sÀtt och till och med innehöll en lösning, gav det en kÀnsla av att nÄgot hade missats. Försöket att klargöra hur forskaren lyckades kringgÄ den uppenbara storlekskontrollen före anropet till strcpy och hur buffertens storlek keyval blev mindre Àn storleken pÄ de lÀsta data ledde till detaljerade men inte sÀrskilt informativa förklaringar som bara upprepade allmÀnna orsaker till buffertöverskridning, som inte var relaterade till den specifika Curl-koden. Svaren pÄminde om kommunikation med en AI-assistent och efter att ha spenderat halva dagen pÄ meningslösa försök att ta reda pÄ hur problemet faktiskt manifesterar sig, var utvecklaren slutligen övertygad om att det inte fanns nÄgon sÄrbarhet i verkligheten.
KĂ€lla: opennet.ru
