Daniel Stenberg 是通过网络curl 接收和发送数据的实用程序的作者，他批评了在创建漏洞报告时使用人工智能工具。此类报告内容详实，语言通俗，看上去质量很高，但如果没有经过深思熟虑的分析，实际上只能是误导性的，用看似高质量的垃圾内容代替了真正的问题。
Curl 项目为发现新漏洞提供奖励，目前已收到 415 份潜在问题报告，其中只有 64 份被确认为漏洞，77 份为非安全漏洞。因此，66% 的报告不包含任何有用的信息，只会占用开发人员本可以花在有用的事情上的时间。
开发人员被迫浪费大量时间解析无用的报告并多次仔细检查其中包含的信息，因为设计的外部质量增加了对信息的信心，并且有一种开发人员误解了某些内容的感觉。另一方面，生成这样的报告只需要申请人付出很少的努力，他们不会费心去检查真正的问题，而只是盲目地复制从人工智能助手那里收到的数据，希望在获得奖励的斗争中碰运气。
给出了此类垃圾报告的两个示例。在计划披露有关危险的 2023 月漏洞 (CVE-38545-XNUMX) 的信息的前一天，通过 Hackerone 发送了一份报告，表明包含修复程序的补丁已公开可用。事实上，该报告混合了有关类似问题的事实以及谷歌人工智能助手巴德编制的有关过去漏洞的详细信息片段。结果，这些信息看起来是新的、相关的，与现实毫无联系。
第二个示例涉及 28 月 XNUMX 日收到的有关 WebSocket 处理程序中缓冲区溢出的消息，该消息由已通过 Hackerone 向各个项目通报漏洞的用户发送。作为重现该问题的方法，报告中包含了有关传递修改后的请求的一般性内容，该请求的值大于使用 strcpy 进行复制时所使用的缓冲区的大小。该报告还提供了一个更正示例（用 strncpy 替换 strcpy 的示例），并指出了代码行“strcpy(keyval, randstr)”的链接，据申请人称，该代码行包含错误。
开发人员仔细检查了三遍，并没有发现任何问题，但由于报告写得很自信，甚至包含了更正，所以有一种少了东西的感觉。试图澄清研究人员如何设法绕过 strcpy 调用之前存在的显式大小检查，以及 keyval 缓冲区的大小如何小于读取数据的大小，从而获得了详细但不包含附加信息的解释仅探讨与特定 Curl 代码无关的缓冲区溢出的明显常见原因。得到的答案让人想起与人工智能助手的沟通，在花了半天时间毫无意义地尝试找出问题的具体表现之后，开发人员最终确信实际上不存在漏洞。
来源： opennet.ru