Masalah amarga laporan kerentanan sing disiapake dening alat AI

Daniel Stenberg, penulis sarana kanggo nampa lan ngirim data liwat curl jaringan, ngritik panggunaan alat AI nalika nggawe laporan kerentanan. Laporan kasebut kalebu informasi sing rinci, ditulis ing basa normal lan katon berkualitas tinggi, nanging tanpa analisa sing dipikirake, nyatane mung bisa nyasab, ngganti masalah nyata karo konten sampah sing katon berkualitas tinggi.

Proyek Curl mbayar ganjaran kanggo ngenali kerentanan anyar lan wis nampa 415 laporan masalah potensial, sing mung 64 dikonfirmasi minangka kerentanan lan 77 minangka bug non-keamanan. Mangkono, 66% kabeh laporan ora ngemot informasi sing migunani lan mung njupuk wektu saka pangembang sing bisa digunakake kanggo perkara sing migunani.

Pangembang dipeksa mbuwang akeh wektu kanggo ngurai laporan sing ora ana gunane lan mriksa kaping pindho informasi sing ana ing kono, amarga kualitas njaba desain nggawe kapercayan tambahan ing informasi kasebut lan ana perasaan manawa pangembang salah paham. Ing tangan liyane, ngasilaken laporan kuwi mbutuhake gaweyan minimal saka pelamar, sing ora keganggu mriksa kanggo masalah nyata, nanging mung wuta nyalin data ditampa saka asisten AI, ngarep-arep kanggo luck ing perjuangan kanggo nampa ganjaran.

Loro conto laporan sampah kasebut diwenehake. Dina sadurunge pambocoran informasi sing direncanakake babagan kerentanan Oktober sing mbebayani (CVE-2023-38545), laporan dikirim liwat Hackerone manawa tembelan kanthi ndandani wis kasedhiya kanggo umum. Nyatane, laporan kasebut ngemot campuran fakta babagan masalah sing padha lan potongan informasi rinci babagan kerentanan kepungkur sing disusun dening asisten AI Google Bard. AkibatΓ©, informasi kasebut katon anyar lan relevan, lan ora ana hubungane karo kasunyatan.

Conto kapindho babagan pesen sing ditampa tanggal 28 Desember babagan kebanjiran buffer ing panangan WebSocket, dikirim dening pangguna sing wis ngandhani macem-macem proyek babagan kerentanan liwat Hackerone. Minangka cara kanggo ngasilake masalah, laporan kasebut kalebu tembung umum babagan ngliwati panjalukan sing diowahi kanthi nilai sing luwih gedhe tinimbang ukuran buffer sing digunakake nalika nyalin karo strcpy. Laporan kasebut uga menehi conto koreksi (conto ngganti strcpy karo strncpy) lan nuduhake link menyang baris kode "strcpy(keyval, randstr)", sing, miturut pelamar, ana kesalahan.

Pangembang mriksa kabeh kaping telu lan ora nemokake masalah, nanging amarga laporan kasebut ditulis kanthi yakin lan malah ana koreksi, ana perasaan yen ana sing ilang ing endi wae. Upaya kanggo njlentrehake carane peneliti bisa ngliwati cek ukuran eksplisit sadurunge telpon strcpy lan carane ukuran buffer keyval dadi kurang saka ukuran data sing diwaca nyebabake rinci, nanging ora nggawa informasi tambahan, panjelasan. sing mung chewed ing nimbulakΓ© umum ketok buffer overflow ora related kanggo kode Curl tartamtu. Jawaban kasebut kaya sesambungan karo asisten AI, lan sawise ngentekake setengah dina ing upaya sing ora ana gunane kanggo ngerteni persis kepiye masalah kasebut, pangembang pungkasane yakin manawa ora ana kerentanan.

Source: opennet.ru

Add a comment