Daniel Stenberg, autorul unui utilitar pentru primirea și trimiterea de date prin curl de rețea, a criticat utilizarea instrumentelor AI la crearea rapoartelor de vulnerabilitate. Astfel de rapoarte includ informații detaliate, sunt scrise într-un limbaj normal și arată de înaltă calitate, dar fără o analiză atentă în realitate, ele pot fi doar înșelătoare, înlocuind problemele reale cu conținut de gunoi cu aspect de înaltă calitate.
Proiectul Curl plătește recompense pentru identificarea de noi vulnerabilități și a primit deja 415 rapoarte de probleme potențiale, dintre care doar 64 au fost confirmate ca vulnerabilități și 77 ca erori non-securitate. Astfel, 66% din toate rapoartele nu au conținut nicio informație utilă și au luat doar timp de la dezvoltatori care ar fi putut fi cheltuit pentru ceva util.
Dezvoltatorii sunt nevoiți să piardă mult timp analizând rapoarte inutile și verificând de mai multe ori informațiile conținute acolo, deoarece calitatea externă a designului creează o încredere suplimentară în informații și există sentimentul că dezvoltatorul a înțeles ceva greșit. Pe de altă parte, generarea unui astfel de raport necesită un efort minim din partea solicitantului, care nu se deranjează să verifice o problemă reală, ci pur și simplu copiază orbește datele primite de la asistenții AI, sperând să aibă noroc în lupta pentru a primi o recompensă.
Sunt date două exemple de astfel de rapoarte de gunoi. Cu o zi înainte de dezvăluirea planificată a informațiilor despre vulnerabilitatea periculoasă din octombrie (CVE-2023-38545), prin Hackerone a fost trimis un raport că patch-ul cu remedierea a devenit disponibil public. De fapt, raportul conținea un amestec de fapte despre probleme similare și fragmente de informații detaliate despre vulnerabilitățile anterioare compilate de asistentul AI al Google, Bard. Ca urmare, informațiile păreau noi și relevante și nu aveau nicio legătură cu realitatea.
Al doilea exemplu se referă la un mesaj primit pe 28 decembrie despre un buffer overflow în handlerul WebSocket, trimis de un utilizator care informase deja diverse proiecte despre vulnerabilități prin Hackerone. Ca metodă de reproducere a problemei, raportul a inclus cuvinte generale despre trecerea unei cereri modificate cu o valoare mai mare decât dimensiunea buffer-ului utilizat la copierea cu strcpy. Raportul a oferit, de asemenea, un exemplu de corecție (un exemplu de înlocuire a strcpy cu strncpy) și a indicat o legătură către linia de cod „strcpy(keyval, randstr)”, care, potrivit solicitantului, conținea o eroare.
Dezvoltatorul a verificat totul de trei ori și nu a găsit probleme, dar din moment ce raportul a fost scris cu încredere și chiar conținea o corecție, a existat sentimentul că ceva lipsește undeva. O încercare de a clarifica modul în care cercetătorul a reușit să ocolească verificarea explicită a dimensiunii prezentă înainte de apelul strcpy și modul în care dimensiunea buffer-ului keyval s-a dovedit a fi mai mică decât dimensiunea datelor citite a condus la explicații detaliate, dar fără a furniza informații suplimentare. care a mestecat doar cauzele comune evidente ale depășirii tamponului care nu au legătură cu codul Curl specific. Răspunsurile aminteau de comunicarea cu un asistent AI, iar după ce a petrecut o jumătate de zi încercări inutile de a afla exact cum se manifestă problema, dezvoltatorul s-a convins în sfârșit că nu există de fapt nicio vulnerabilitate.
Sursa: opennet.ru