AI-моделът Claude Opus 4.6 открива над 500 предварително неизвестни уязвимости

Компанията Anthropic обяви разширяване на AI моделите Claude Opus 4.6 с нови възможности за откриване на уязвимости в кода и сподели резултатите от експеримент, в който бяха открити над 500 досега неизвестни (0-day) уязвимости в последните версии на различни отворени проекти. Работата беше фокусирана върху издирването на уязвимости, причинени от проблеми с паметта, тъй като наличието им е по-лесно за проверка. На всички открити уязвимости е присвоен висок ниво на опасност. Всяка уязвимост беше ръчно проверена и потвърдена от служителите на Anthropic или привлечени външни изследователи по сигурността.

За анализа на уязвимостите бяха ангажирани кодови бази на популярни отворени проекти, които вече дълго време преминават непрекъснато fuzzing тестване в услугата OSS-Fuzz. В контекста на fuzzing тестването, при което се генерира поток от всякакви случайни комбинации на входни данни, AI моделът се опитваше да анализира кода, като отчита предишни корекции, за да идентифицира подобни неустранени грешки, изолирайки проблемни шаблони и логически извеждайки, кои входни данни могат да нарушат хода на изпълнението.

Информацията за откритите по време на експеримента уязвимости вече е започнала да се предава на поддържащите, с които се води съвместна работа по приемането на корекции. За да помогне на поддържащите, по време на проведената проверка бяха разработени патчи за отстраняване на откритите проблеми. Като пример са изброени три уязвимости в GhostScript, OpenSC и CGIF, които в момента на публикуване бяха отстранени от поддържащите.

Конфигурацията, използвана за откриване на проблеми, не беше подобна на традиционните системи за автоматично откриване на уязвимости — на моделите Claude Opus 4.6 беше предоставен достъп до виртуална машина, в която освен изследвания код бяха инсталирани типични инструменти за разработчици (coreutils, Python и т.н.) и утилити за отладка и анализ на уязвимости (включително утилити за fuzzing тестване). На моделите не беше дадена ясна инструкция за употреба на тези инструменти и не бяха предоставени специални сведения относно методите за откриване на уязвимости. На моделите беше поставена единствено задачата и предоставена възможност сама да разсъждава за оптималното използване на наличните инструменти.

При търсене на уязвимости в GhostScript, AI-моделът първоначално опита да проведе тестове с fuzzing, но когато това не доведе до резултат, премина към анализ на кода. Анализът на кода също не даде резултат и тогава моделът започна да изучава историята на промените в git и в един от комитите забеляза споменаване на проверка на границите на буфера. Разбирайки комита, моделът определи, че корекцията е добавила липсваща проверка на границите на буфера при обработка на шрифтове.

След това моделът определи кода, който е бил преди корекцията, и се опита да намери в останалата част от кода сходни модели на използване на проблемната функция, които остават неизправени. В крайна сметка в файла gdevpsfx.c беше установен извикване на функцията gs_type1_blend без проверка на валидността на стойностите. В крайна сметка моделът подбра съдържанието на файла, обработката на което доведе до срив поради запис на данни в паметта извън заделения буфер.

В CGIF AI-моделът изхождаше от предпоставката, че при разархивиране на GIF файлове библиотеката разглежда, че размерът на компресираните данни винаги е по-малък от разархивираните. Търсенето на уязвимостта беше съсредоточено върху определянето на условията, при които компресираните с LZW алгоритъм данни ще надвишават разархивираните. Подобни условия бяха намерени и AI-моделът успя да формулира GIT файл, чиято обработка доведе до препълване на буфера. В OpenSC проблемът беше открит след анализ на използването на потенциално опасни функции strrchr и strcat.

Отбелязва се, че езиковите модели достигнаха ниво, което позволява откриването на преди неизвестни уязвимости, и в близко бъдеще ще надминат експертите по сигурността по бързина и мащаб на търсене на уязвимости. Предполага се, че увеличаването на броя на откритите уязвимости ще изисква реформиране на съществуващите процеси на разкриване на информация, тъй като предоставянето на 90 дни за корекции в момента няма да бъде достатъчно.

Източник: opennet.ru