Daniel Stenberg, creator of the curl data transfer utility, criticized the use of AI tools to create vulnerability reports. Such reports provide detailed information, written in plain language, and seem high-quality, but without thoughtful analysis can mislead, substituting real issues with superficially appealing content.
The Curl project rewards the discovery of new vulnerabilities and has already received 415 reports of potential issues, of which only 64 were confirmed as vulnerabilities and 77 as irrelevant security errors. Thus, 66% of all reports contained no useful information and merely wasted developers' time that could have been spent on something productive.
Developers are forced to waste a lot of time examining useless reports and rechecking the information provided multiple times, as the external quality of the presentation creates additional trust in the information, leading to the impression that the developer misunderstood something. On the other hand, generating such a report requires minimal effort from the claimant, who does not bother to verify the existence of a real problem and simply blindly copies data received from AI assistants, hoping for luck in the quest for rewards.
Two examples of such garbage reports are provided. A day before the scheduled disclosure of information about the October critical vulnerability (CVE-2023-38545), a report was submitted through Hackerone stating that the patch was made publicly available. In reality, the report contained a mixture generated by the AI assistant Google Bard, consisting of facts about similar problems and excerpts of detailed information about past vulnerabilities. As a result, the information appeared new and relevant, but had no connection to reality.
Al doilea exemplu se referă la mesajul primit pe 28 decembrie despre overflow-ul de buffer în handlerul WebSocket, trimis de utilizatorul care a informat deja diferite proiecte despre vulnerabilități prin Hackerone. Metoda de reproducere a problemei în raport menționa cuvinte generale despre trimiterea unei cereri modificate cu o valoare care depășește dimensiunea buffer-ului utilizat în timpul copierei cu ajutorul strcpy. În raport a fost inclus și un exemplu de corectare (înlocuirea strcpy cu strncpy) și a fost menționată o linie de cod „strcpy(keyval, randstr)”, în care, conform solicitantului, a avut loc o eroare.
Dezvoltatorul a verificat totul de trei ori și nu a găsit nicio problemă, dar, deoarece raportul a fost scris cu încredere și includea chiar și o soluție, a apărut senzația că undeva ceva lipsește. O încercare de a clarifica cum a reușit cercetătorul să ocolească verificarea explicită a dimensiunii înainte de a apela strcpy și cum dimensiunea buffer-ului keyval s-a dovedit a fi mai mică decât dimensiunea datelor citite, a dus la obținerea unor explicații detaliate, dar fără informații suplimentare, care doar reiteraau cauzele evidente ale overflow-ului de buffer, fără legătură cu codul specific Curl. Răspunsurile semănau cu o conversație cu un asistent AI și, după ce a petrecut o jumătate de zi în încercări inutile de a înțelege cum se manifestă problema, dezvoltatorul s-a convins în cele din urmă că nu există nicio vulnerabilitate de fapt.
Sursa: opennet.ro
