Даниел Стенберг, автор на помощна програма за получаване и изпращане на данни през мрежата, критикува използването на AI инструменти при създаване на доклади за уязвимости. Такива отчети включват подробна информация, написани са на нормален език и изглеждат висококачествени, но без обмислен анализ в действителност те могат само да бъдат подвеждащи, заменяйки реални проблеми с качествено изглеждащо боклук.
Проектът Curl плаща награди за идентифициране на нови уязвимости и вече е получил 415 доклада за потенциални проблеми, от които само 64 са потвърдени като уязвимости и 77 като бъгове, които не са свързани със сигурността. По този начин 66% от всички доклади не съдържат никаква полезна информация и само отнемат време на разработчиците, което може да бъде изразходвано за нещо полезно.
Разработчиците са принудени да губят много време в анализиране на безполезни отчети и двойна проверка на съдържащата се там информация няколко пъти, тъй като външното качество на дизайна създава допълнителна увереност в информацията и има чувството, че разработчикът е разбрал нещо погрешно. От друга страна, генерирането на такъв отчет изисква минимални усилия от кандидата, който не си прави труда да проверява за реален проблем, а просто копира сляпо данните, получени от AI асистенти, надявайки се на късмет в борбата за получаване на награда.
Дадени са два примера за такива отчети за отпадъци. В деня преди планираното разкриване на информация за опасната октомврийска уязвимост (CVE-2023-38545), чрез Hackerone беше изпратен доклад, че корекцията с корекцията е станала публично достъпна. Всъщност докладът съдържаше смесица от факти за подобни проблеми и откъси от подробна информация за минали уязвимости, събрана от AI асистента на Google Бард. В резултат на това информацията изглеждаше нова и актуална и нямаше връзка с реалността.
Вторият пример се отнася до съобщение, получено на 28 декември за препълване на буфера в манипулатора на WebSocket, изпратено от потребител, който вече е информирал различни проекти за уязвимости чрез Hackerone. Като метод за възпроизвеждане на проблема докладът включва общи думи за предаване на модифицирана заявка със стойност, по-голяма от размера на буфера, използван при копиране със strcpy. Докладът също така предостави пример за корекция (пример за замяна на strcpy със strncpy) и посочи връзка към реда с код „strcpy(keyval, randstr)“, който според заявителя съдържа грешка.
Разработчикът провери всичко три пъти и не откри никакви проблеми, но тъй като докладът беше написан уверено и дори съдържаше корекция, имаше чувството, че нещо липсва някъде. Опитът да се изясни как изследователят успява да заобиколи изричната проверка на размера, присъстваща преди извикването на strcpy и как размерът на буфера keyval се оказва по-малък от размера на прочетените данни, доведе до подробни, но неносещи допълнителна информация обяснения които само дъвчат очевидните често срещани причини за препълване на буфера, които не са свързани с конкретен код на Curl. Отговорите напомняха комуникация с AI асистент и след като прекара половин ден в безсмислени опити да разбере как точно се проявява проблемът, разработчикът най-накрая беше убеден, че всъщност няма уязвимост.
Източник: opennet.ru