Curl-författaren kritiserar AI-genererade säkerhetsrapporter

Några dagar sen, Daniel Stenberg (författaren till Curl) gjorde det känt på din blogg, ett inlägg där den uttrycker sig inte bara som en kritiserar användningen av artificiell intelligensverktyg, men i form av ett klagomål, besväret som detta genererar för honom och hans team, säkerhetsrapporterna som genereras av artificiella intelligensverktyg.

Och i sin publikation, Daniel Stenberg nämner att under många år processen att verifiera alla rapporter och kassera mellan "skräp" och "riktiga" säkerhetsproblem, Det var inget som krävde extra ansträngning., eftersom den nämner att "skräprapporter också vanligtvis har varit mycket enkla och snabba att upptäcka och kassera."

Med den senaste tidens uppgång av artificiell intelligens, många uppgifter som tidigare krävde många timmars mänskligt ingripande har revolutionerats. Bland de mest nämnda fallen i den här bloggen har vi tagit upp ämnena AI: er dedikerade till programmering, bildgenerering och videoredigering, som ChatGPT, Copilot, Bard, bland andra.

Inom det specifika området för programmering genererade Copilot många kritik, den största oro var möjligheten att ställas inför rättsliga stämningar. Men i andra änden av skalan har ingripandet av artificiell intelligens avsevärt förändrat olika områden. Till exempel, för att upptäcka fel och säkerhetsproblem i kod, har AI:er spelat en avgörande roll. Många människor har använt dessa verktyg för att identifiera potentiella buggar och sårbarheter i kod, och deltar ofta i bounty-program för att upptäcka säkerhetsproblem.

Curl undgick inte denna trend, och Daniel Stenberg uttryckte på hans blogg att Efter flera månader av att hålla tillbaka sin åsikt exploderade han till slut håller inte med om användningen av artificiell intelligens. Anledningen bakom din frustration Det var växande antal "skräp"-rapporter som genereras av användningen av dessa verktyg.

I publikationen lyfts det fram att Dessa rapporter har ett detaljerat utseende, är skrivna på normalt språk och verkar vara av hög kvalitet. Men utan noggrann analys visar de sig vara vilseledande, eftersom de ersätter verkliga problem med innehåll av låg kvalitet som verkar vara värdefullt.

Projektet Curl, som erbjuder belöningar för identifiering av nya sårbarheter, har mottagit totalt 415 rapporter om potentiella problem. Från denna uppsättning, endast 64 bekräftades som verkliga sårbarheter, 77 beskrev icke-säkerhetsrelaterade fel och, överraskande nog, 274 (66 %) innehöll inte användbar information, äta upp utvecklarnas tid som kunde ha lagts på något användbart.

Utvecklare tvingas slösa mycket tid på att analysera värdelösa rapporter och upprepade gånger kontrollera informationen i dem, eftersom den externa kvaliteten på designen skapar ytterligare förtroende för informationen och det finns en känsla av att utvecklaren inte förstod något.

Å andra sidan kräver att generera en sådan rapport minimal ansträngning från begäranden, som inte bryr sig om att kontrollera om det finns ett verkligt problem, utan helt enkelt blindt kopierar data som tas emot från AI-assistenterna i hopp om att ha tur i kampen för att få en belöning.

Daniel Stenberg, Dela två exempel på den här typen av soprapportering:

1. I det första fallet, precis innan det planerade släppet av information om en kritisk sårbarhet i oktober, mottogs en rapport via HackerOne som indikerade att det redan fanns en offentlig patch för att lösa problemet. Rapporten visade sig dock vara "falsk", eftersom den innehöll data om liknande problem och utdrag av detaljerad information om tidigare sårbarheter, sammanställda av Googles assistent för artificiell intelligens, Bard. Även om informationen verkade ny och relevant, saknade den koppling till verkligheten.
2. I det andra fallet inkom en rapport om ett buffertspill i WebSocket-hanteringen. Denna rapport kom från en användare som redan hade rapporterat sårbarheter till flera projekt genom HackerOne. För att återskapa problemet gav rapporten allmänna instruktioner om hur man skickar en modifierad begäran och ett exempel på korrigering.

Trots en noggrann trippelkontroll av koden hittade utvecklaren inga problem. Men eftersom rapporten var skriven på ett sådant sätt att den skapade "viss" förtroende och till och med presenterade ett förslag till lösning, kvarstod känslan av att något inte stämde.

I ett försök att klargöra hur användaren lyckades kringgå storlekskontrollen nämns det att förklaringarna inte innehöll någon ytterligare information och bara diskuterade uppenbara vanliga orsaker till buffertspill som inte var relaterade till Curl-koden. Svaren påminde om att kommunicera med en AI-assistent, och efter meningslösa försök att ta reda på exakt hur problemet yttrade sig, blev Daniel Stenberg till slut övertygad om att ingen sårbarhet faktiskt existerade och stängde ämnet som inte "tillämpligt".

Slutligen, om du är intresserad av att kunna veta mer om det, kan du konsultera detaljerna i följande länk.