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
