Daniel Stenberg, the author of the network data transmission tool curl, has criticized the use of AI tools in vulnerability reporting. Such reports may include detailed information, are written in plain language, and appear well-crafted, but without thoughtful analysis, they can mislead, replacing real issues with superficially appealing garbage content.
The Curl project offers rewards for discovering new vulnerabilities and has already received 415 reports of potential issues, of which only 64 were confirmed as vulnerabilities, while 77 were identified as non-security-related bugs. Thus, 66% of all reports contained no useful information and only wasted developers' time that could have been better spent on meaningful tasks.
Developers are forced to waste a lot of time sifting through useless reports and double-checking the information provided multiple times, as the external quality of presentation adds an additional trust to the data, creating an impression that the developer misunderstood something. On the other hand, producing such a report requires minimal effort from the claimant, who does not trouble themselves with verifying the existence of a real problem but merely blindly copies data obtained from AI assistants, hoping for luck in the reward chase.
Two examples of such garbage reports are provided. A day before the scheduled disclosure of details about the October critical vulnerability (CVE-2023-38545), a report was submitted via Hackerone indicating that the patch had been made publicly available. In reality, the report contained a compilation by the AI assistant Google Bard of facts about similar issues and excerpts of detailed information about past vulnerabilities. As a result, the information appeared new and relevant but was disconnected from reality.
The second example pertains to a buffer overflow message from December 28 in the WebSocket handler, sent by a user who had already informed several projects about vulnerabilities through Hackerone. The report mentioned a general method for reproducing the issue involving sending a modified request with a value size exceeding the buffer size used in copying via strcpy. The report also included an example fix (changing strcpy to strncpy) and referenced the line of code "strcpy(keyval, randstr)" where the submitter believed there was an error.
The developer triple-checked everything and found no problems, but since the report was written confidently and even contained a fix, there was a feeling that something was being overlooked. An attempt to clarify how the researcher managed to bypass the explicit size check present before the strcpy call and how the keyval buffer size was less than the size of the read data resulted in detailed but unhelpful explanations that merely reiterated obvious general reasons for buffer overflow unrelated to the specific Curl code. The responses felt like communicating with an AI assistant, and after spending half a day in fruitless attempts to discern how the problem manifested, the developer ultimately concluded that there was no actual vulnerability.
Source: opennet.ru
