Деніел 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 виявився меншим за розмір прочитаних даних, призвела до отримання докладних, але не несучих додаткової інформації, пояснень, які лише розжовували очевидні загальні причини виникнення переповнення. Відповіді нагадували спілкування з AI-помічником і витративши пів дня на безглузді спроби дізнатися, як саме проявляється проблема, розробник остаточно переконався, що ніякої вразливості насправді немає.
Джерело: opennet.ru
