Daniel Stenberg, programos, skirtos duomenims gauti ir siųsti tinkle, autorius, kritikavo AI įrankių naudojimą kuriant pažeidžiamumo ataskaitas. Tokiose ataskaitose pateikiama išsami informacija, jos parašytos įprasta kalba ir atrodo kokybiškai, tačiau be apgalvotos analizės realybėje gali būti tik klaidinančios, realias problemas pakeisdamos kokybiškai atrodančiu šiukšlių turiniu.
„Curl“ projektas moka atlygį už naujų pažeidžiamumų nustatymą ir jau gavo 415 pranešimų apie galimas problemas, iš kurių tik 64 buvo patvirtinti kaip pažeidžiamumas, o 77 – kaip su sauga nesusijusios klaidos. Taigi 66% visų ataskaitų nepateikė jokios naudingos informacijos ir tik atėmė iš kūrėjų laiką, kurį buvo galima skirti kažkam naudingam.
Kūrėjai yra priversti sugaišti daug laiko analizuodami nenaudingas ataskaitas ir kelis kartus tikrindami ten esančią informaciją, nes išorinė dizaino kokybė sukuria papildomą pasitikėjimą informacija ir kyla jausmas, kad kūrėjas kažką nesuprato. Kita vertus, tokios ataskaitos sukūrimas reikalauja minimalių pastangų iš pareiškėjo, kuris nesivargina tikrindamas, ar nėra realios problemos, o tiesiog aklai kopijuoja iš AI padėjėjų gautus duomenis, tikėdamasis sėkmės kovoje dėl atlygio.
Pateikiami du tokių pranešimų apie šiukšles pavyzdžiai. Dieną prieš planuojamą informacijos apie pavojingą spalio pažeidžiamumą (CVE-2023-38545) atskleidimą per „Hackerone“ buvo išsiųstas pranešimas, kad pataisa su pataisa tapo viešai prieinama. Tiesą sakant, ataskaitoje buvo įvairių faktų apie panašias problemas ir išsamios informacijos apie praeities pažeidžiamumą fragmentų, kuriuos sudarė „Google“ AI padėjėjas Bardas. Dėl to informacija atrodė nauja ir aktuali, neturėjo jokio ryšio su realybe.
Antrasis pavyzdys yra susijęs su pranešimu, gautu gruodžio 28 d. apie buferio perpildymą WebSocket tvarkyklėje, išsiųstą vartotojo, kuris per Hackerone jau informavo įvairius projektus apie pažeidžiamumą. Kaip problemos atkūrimo būdas, ataskaitoje buvo pateikti bendrieji žodžiai apie modifikuotos užklausos, kurios vertė yra didesnė už buferio, naudojamo kopijuojant su strcpy, perdavimą. Ataskaitoje taip pat buvo pateiktas taisymo pavyzdys (strcpy pakeitimo strncpy pavyzdys) ir nurodyta nuoroda į kodo eilutę „strcpy(keyval, randstr)“, kurioje, pareiškėjo teigimu, buvo klaida.
Kūrėjas dar kartą viską patikrino tris kartus ir jokių problemų nerado, bet kadangi ataskaita buvo surašyta užtikrintai ir net jame buvo pataisymas, atsirado jausmas, kad kažkur kažko trūksta. Bandymas išsiaiškinti, kaip tyrėjui pavyko apeiti aiškų dydžio patikrinimą, kuris buvo prieš strcpy iškvietimą ir kaip raktinio elemento buferio dydis pasirodė mažesnis už nuskaitytų duomenų dydį, paskatino išsamius, bet papildomos informacijos nenešančius paaiškinimus. kad tik kramtė akivaizdžias bendras buferio perpildymo priežastis, nesusijusias su konkrečiu Curl kodu. Atsakymai priminė bendravimą su dirbtinio intelekto asistentu, o praleidęs pusdienį beprasmiškiems bandymams išsiaiškinti, kaip tiksliai pasireiškia problema, kūrėjas galiausiai įsitikino, kad pažeidžiamumo iš tiesų nėra.
Šaltinis: opennet.ru