Деніел Cтенберг (Daniel Stenberg), автор утиліти для отримання та відправлення даних по мережі curl, виступив із критикою використання AI-інструментів при створенні звітів про вразливості. Подібні звіти включають детальні відомості, написані нормальною мовою і виглядають якісними, але без вдумливого аналізу насправді можуть лише вводити в оману, підмінюючи реальні проблеми сміттєвим вмістом, що якісно виглядає.
Проект Curl виплачує винагороди за виявлення нових уразливостей і вже отримав 415 звітів про потенційні проблеми, з яких лише 64 були підтверджені як уразливості, а 77 як не пов'язані з безпекою помилки. Таким чином 66% усіх звітів не містили будь-яких корисних відомостей і лише відібрали у розробників час, який можна було витратити на щось корисне.
Розробники змушені даремно витрачати багато часу на розбір марних звітів і перевіряти ще раз зазначені там відомості по кілька разів, так як зовнішня якість оформлення викликає додаткову довіру до інформації і виникає відчуття, що розробник щось недозрозумів. З іншого боку, формування подібного звіту вимагає мінімальних зусиль від заявника, який не обтяжує себе перевіркою наявності реальної проблеми, а просто сліпо копіює дані, отримані від AI-помічників, сподіваючись на везіння у боротьбі за отримання винагороди.
Наводиться два приклади таких звітів. За день до планового розкриття відомостей про жовтневу небезпечну вразливість (CVE-2023-38545) через Hackerone було надіслано звіт про те, що патч із виправленням потрапив у відкритий доступ. Насправді звіт містив скомпоновану AI-помічником Google Bard суміш із фактів про схожі проблеми та уривки детальних відомостей про минулі вразливості. У результаті інформація виглядала новою та актуальною, не мала в'яза з реальністю.
Другий приклад стосується отриманого 28 грудня повідомлення про переповнення буфера в обробнику WebSocket, відправлене користувачем, що вже інформував про уразливості різні проекти через Hackerone. Як метод повторення проблеми у звіті вказувалися загальні слова про передачу зміненого запиту з розміром значення, що перевищує розмір буфера, що використовується при копіюванні за допомогою strcpy. У звіті також наводився приклад виправлення (приклад заміни strcpy на strncpy) і вказувалося посилання рядок коду «strcpy(keyval, randstr)», у якому на думку заявника була помилка.
Розробник три рази все перевірив ще раз і не знайшов якихось проблем, але так як звіт написаний впевнено і навіть містив виправлення, виникло відчуття, що десь щось упускається. Спроба уточнити як досліднику вдалося обійти присутню до виклику strcpy явну перевірку розміру і як розмір буфера keyval виявився меншим за розмір прочитаних даних, призвела до отримання докладних, але не несучих додаткової інформації, пояснень, які лише розжовували очевидні загальні причини виникнення переповнення. конкретним кодом Curl. Відповіді нагадували спілкування з AI-помічником і витративши пів дня на безглузді спроби дізнатися, як саме проявляється проблема, розробник остаточно переконався, що ніякої вразливості насправді немає.
Джерело: opennet.ru