Daniel Stenberg, avtor pripomočka za sprejemanje in pošiljanje podatkov prek omrežnega kodra, je kritiziral uporabo orodij AI pri ustvarjanju poročil o ranljivosti. Takšna poročila vsebujejo podrobne informacije, so napisana v običajnem jeziku in izgledajo kakovostno, vendar so brez premišljene analize v resnici lahko le zavajajoča in resnične težave nadomestijo s kakovostno navidezno smeti.
Projekt Curl plačuje nagrade za odkrivanje novih ranljivosti in je prejel že 415 poročil o morebitnih težavah, od katerih jih je bilo le 64 potrjenih kot ranljivosti in 77 kot nevarnostne hrošče. Tako 66 % vseh poročil ni vsebovalo nobenih koristnih informacij in je razvijalcem le vzelo čas, ki bi ga lahko porabili za kaj koristnega.
Razvijalci so prisiljeni izgubiti veliko časa z razčlenjevanjem neuporabnih poročil in večkratnim dvojnim preverjanjem tam vsebovanih informacij, saj zunanja kakovost zasnove ustvarja dodatno zaupanje v informacije in obstaja občutek, da je razvijalec nekaj narobe razumel. Po drugi strani pa izdelava takšnega poročila zahteva minimalen trud prosilca, ki se ne trudi preveriti, ali gre za resnično težavo, ampak preprosto slepo kopira podatke, prejete od pomočnikov AI, v upanju na srečo v boju za nagrado.
Podana sta dva primera takih poročil o smeti. Dan pred načrtovanim razkritjem informacije o nevarni oktobrski ranljivosti (CVE-2023-38545) je bilo prek Hackerona poslano poročilo, da je popravek s popravkom postal javno dostopen. Pravzaprav je poročilo vsebovalo mešanico dejstev o podobnih težavah in delčke podrobnih informacij o preteklih ranljivostih, ki jih je zbral Googlov pomočnik za umetno inteligenco Bard. Posledično so bile informacije videti nove in relevantne ter niso imele nobene povezave z realnostjo.
Drugi primer se nanaša na sporočilo, prejeto 28. decembra, o prekoračitvi medpomnilnika v upravljalniku WebSocket, ki ga je poslal uporabnik, ki je prek Hackerona že obvestil različne projekte o ranljivostih. Kot metodo reprodukcije težave je poročilo vključevalo splošne besede o posredovanju spremenjene zahteve z vrednostjo, večjo od velikosti medpomnilnika, uporabljenega pri kopiranju s strcpy. V poročilu je bil podan tudi primer popravka (primer zamenjave strcpy s strncpy) in navedena povezava do vrstice kode »strcpy(keyval, randstr)«, ki je po mnenju vlagatelja vsebovala napako.
Razvijalec je vse trikrat dvakrat preveril in ni našel nobenih težav, a ker je bilo poročilo napisano samozavestno in je vsebovalo celo popravek, je bil občutek, da nekje nekaj manjka. Poskus razjasnitve, kako je raziskovalcu uspelo zaobiti eksplicitno preverjanje velikosti, ki je bilo prisotno pred klicem strcpy, in kako se je izkazalo, da je velikost vmesnega pomnilnika keyval manjša od velikosti prebranih podatkov, je vodil do podrobnih razlag, ki pa niso nosile dodatnih informacij. ki je samo prežvečil očitne pogoste vzroke za prepolnitev medpomnilnika, ki niso povezani s specifično kodo Curl. Odgovori so spominjali na komunikacijo s pomočnikom AI in potem, ko je pol dneva porabil za nesmiselne poskuse, da bi ugotovil, kako natančno se težava kaže, je bil razvijalec končno prepričan, da ranljivosti pravzaprav ni.
Vir: opennet.ru