Даниел Стенбърг (Daniel Stenberg), авторът на инструментa за предаване и получаване на данни по мрежата 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
