В нашем предыдущем посте Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models мы рассказали о фреймворке для исследований уязвимостей при помощи языковых моделей и продемонстрировали его потенциал, усовершенствовав показатели современных бенчмарков CyberSecEval2 компании Meta. С тех пор Naptime эволюционировал в Big Sleep — совместный проект Google Project Zero и Google DeepMind.
Сегодня мы с радостью готовы поделиться первой уязвимостью из реального мира. обнаруженной агентом Big Sleep: отрицательным переполнением (underflow) буфера стека с возможностью реализации эксплойтов в SQLite, — широко используемом опенсорсном движке баз данных. Мы обнаружили уязвимость и сообщили о ней разработчикам в начале октября, и они устранили её в тот же день. К счастью, мы обнаружили эту проблему до её появления в официальном релизе, так что она не затронула пользователей SQLite.
Мы считаем, что это первый публичный пример обнаружения ИИ-агентом ранее неизвестной уязвимости безопасности по памяти в широко используемом реальном ПО. В этом же году на мероприятии DARPA AIxCC команда Team Atlanta обнаружила разыменование нулевого указателя в SQLite, что вдохновило нас использовать его в нашем тестировании, чтобы проверить, сможем ли мы найти более серьёзную уязвимость.
Мы считаем, что наша работа обладает огромным защитным потенциалом. Нахождение уязвимостей в ПО ещё до его релиза не позволит нападающим пользоваться ими: уязвимости устраняются ещё до того, как их увидят злоумышленники. Очень сильно помог в поиске уязвимостей фаззинг, но нам нужна методика, позволяющая защищающимся находить баги, которые сложно (или невозможно) обнаруживать фаззингом, и мы надеемся, что ИИ позволит закрыть этот пробел. Мы считаем, что это многообещающий путь к полному изменению ситуации в кибербезопасности и обеспечению асимметричного преимущества для защищающихся.
Сама уязвимость довольно любопытна, к тому же существующая инфраструктура тестирования SQLite (и через OSS-Fuzz, и через собственную инфраструктуру проекта) не обнаружила проблему, так что мы провели дополнительное исследование.
