Проблеми от подготвените от AI инструменти отчети за уязвимости

Даниел Стенберг (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