Дэниел Cтенберг (Daniel Stenberg), автор утилиты для получения и отправки данных по сети curl, выступил с критикой использования AI-инструментов при создании отчётов об уязвимостях. Подобные отчёты включают детальные сведения, написаны нормальным языком и выглядят качественными, но без вдумчивого анализа на деле могут лишь вводить в заблуждение, подменяя реальные проблемы качественно выглядящим мусорным содержимым.
Проект Curl выплачивает вознаграждения за выявление новых уязвимостей и уже получил 415 отчётов о потенциальных проблемах, из которых лишь 64 были подтверждены как уязвимости, 77 описывали не связанные с безопасностью ошибки, а 274 (66%) не содержали каких-либо полезных сведений и только отняли у разработчиков время, которое можно было потратить на что-то полезное.
Разработчики вынуждены впустую тратить много времени на разбор бесполезных отчётов и перепроверять указанные там сведения по несколько раз, так как внешнее качество оформления вызывает дополнительное доверие к информации и возникает ощущение, что разработчик что-то недопонял. С другой стороны, формирование подобного отчёта требует минимальных усилий от заявителя, который не утруждает себя проверкой наличия реальной проблемы, а просто слепо копирует данные полученные от AI-помощников, надеясь на везение в борьбе за получение вознаграждения.
Приводится два примера таких мусорных отчётов. За день до планового раскрытия сведений об октябрьской опасной уязвимости (CVE-2023-38545) через Hackerone был отправлен отчёт о том, что патч с исправлением попал в открытый доступ. На деле отчёт содержал скомпонованную AI-помощником Google Bard смесь из фактов о похожих проблемах и отрывков детальных сведений о прошлых уязвимостях. В итоге информация выглядела новой и актуальной, но не имела связи с реальностью.
Второй пример затрагивает полученное 28 декабря сообщение о переполнении буфера в обработчике WebSocket, отправленное пользователем, уже информировавшим об уязвимостях разные проекты через Hackerone. В качестве метода повторения проблемы в отчёте указывались общие слова о передаче изменённого запроса с размером значения, превышающего размер буфера, используемого при копировании при помощи strcpy. В отчёте также приводился пример исправления (пример замены strcpy на strncpy) и указывалась ссылка на строку кода "strcpy(keyval, randstr)", в которой по мнению заявителя была ошибка.
Разработчик три раза всё перепроверил и не нашёл каких-либо проблем, но так как отчёт написан уверенно и даже содержал исправление, возникло ощущение, что где-то что-то упускается. Попытка уточнить как исследователю удалось обойти присутствующую до вызова strcpy явную проверку размера и как размер буфера keyval оказался меньше размера прочитанных данных, привела к получению подробных, но не несущих дополнительной информации, пояснений, которые лишь разжёвывали очевидные общие причины возникновения переполнения буфера, не связанные с конкретным кодом Curl. Ответы напоминали общение с AI-помощником и потратив полдня на бессмысленные попытки узнать как именно проявляется проблема, разработчик окончательно убедился, что никакой уязвимости на деле нет.