На тысячу путей к root-доступу меньше

Исследования безопасности, которые раньше требовали отдельного длительного разбора каждой находки, всё чаще можно проводить как систематический процесс. В этом материале мы рассказываем об одной из наших работ в этой области.

Масштабировать поиск уязвимостей становится проще, но определение приоритетов и проверка по-прежнему остаются узкими местами процесса. Мы создали прототип для поиска уязвимостей безопасности в ядре Linux в контролируемой исследовательской среде. Наш прототип выявил и проанализировал 2 308 потенциальных уязвимостей ядра Linux, динамически воспроизвёл 1 724 уязвимости и создал 948 эксплойтов локального повышения привилегий (LPE), которые могли позволить непривилегированному локальному пользователю получить root-доступ.

На основе этих данных мы определили, о каких уязвимостях сообщать в первую очередь, и подготовили патчи для рассмотрения мейнтейнерами. Следуя рекомендациям сообщества ядра Linux, мы начали с критических уязвимостей и совместно с партнёрами Patch the Planet работаем над дальнейшими отчётами и патчами.

В июне в рамках нашей инициативы Patch the Planet мы рассказали, что GPT‑5.5 Cyber выявила уязвимости ядра Linux и разработала 24 эксплойта локального повышения привилегий для их подтверждения и подготовки отчётов. Мы развили эту работу в конвейер на базе готовящейся к выпуску модели для кибербезопасности, охватывающий поиск уязвимостей, динамическую проверку, оценку возможности эксплуатации и генерацию патчей. После завершения его работы исследователи проверили результаты и отправили отчёты об обнаруженных уязвимостях вместе с патчами.

Ядро Linux лежит в основе устройств Android, облачной инфраструктуры, суперкомпьютеров и других систем, которыми пользуются миллиарды людей. Ядро содержит более 40 млн строк кода и имеет обширную поверхность атаки: системные вызовы, сетевые компоненты, файловые системы и драйверы устройств. Мы выбрали Linux, чтобы изучить, насколько эффективно передовые модели могут находить уязвимости и демонстрировать их влияние на безопасность в кодовой базе такого масштаба и значимости.

На начальном этапе поиска были выявлены тысячи потенциальных уязвимостей — слишком много, чтобы исследователи безопасности могли вручную проверить и оценить каждую. Практическая сложность нашего конвейера поиска уязвимостей заключалась не в самом поиске, а в определении того, какие находки воспроизводимы, какую границу безопасности они нарушают и какие требуют первоочередного внимания мейнтейнеров.

Миссия команды OpenAI по кибербезопасности — помогать защищать ПО, на которое опирается весь мир. Мы приводим затраты на API для каждого этапа, чтобы исследователи могли оценить ресурсы, необходимые для воспроизведения и развития этой работы. Эти затраты отражают модели, конфигурации целевых систем и рабочий процесс, использованные в данной оценке. Наша более широкая цель — помочь специалистам по защите находить и исправлять уязвимости, сокращая возможности злоумышленников и повышая для них стоимость эксплуатации уязвимостей ПО.

Наконец, отметим, что в этом исследовании мы сосредоточились на методологии и измерении возможностей моделей, а не на затратах. Мы ожидаем, что достаточная доработка обвязки позволит заметно снизить затраты на каждом этапе, поэтому приведённые суммы скорее отражают их верхнюю границу.

Наш исследовательский прототип — это конвейер из пяти этапов, в основе которого лежит готовящаяся к выпуску модель для кибербезопасности:

• Поиск уязвимостей: агенты определяют значимые для безопасности участки кодовой базы и сканируют их в поисках потенциальных уязвимостей.

• Динамическая проверка: агенты пытаются воспроизвести каждую потенциальную уязвимость в изолированной среде и сохраняют свидетельства, полученные во время выполнения. Результат этого этапа — воспроизведённые и подтверждённые уязвимости.

• Оценка возможности эксплуатации: агенты проверяют, могут ли подтверждённые уязвимости привести к раскрытию информации или локальному повышению привилегий.

• Генерация патчей: агенты создают патчи для устранения каждой выявленной уязвимости.

• Проверка специалистами: исследователи безопасности проверяют эксплойт, патч и предлагаемую оценку серьёзности перед отправкой отчёта мейнтейнерам.

В конце конвейера система объединяет анализ первопричины, минимальный PoC, вызывающий сбой, предлагаемый патч и полноценный эксплойт. Эти материалы помогают исследователям оценить серьёзность уязвимости и передать исправления в основной проект.

Не каждая строка кода ядра Linux значима для безопасности. В нашем конвейере команда агентов-разведчиков определяла наиболее важные объекты аудита, которые затем передавались агентам-аналитикам для поиска уязвимостей.

Агенты-разведчики изучают каждую папку и файл и выбирают объекты аудита с учётом их доступности для пользователей с низкими привилегиями и значимости для безопасности.

На этом этапе были определены 5 034 объекта аудита — около 2,8 млн строк кода, или примерно 7 % всей кодовой базы ядра Linux. Это значительно снизило стоимость аудита безопасности по сравнению с анализом всей кодовой базы. Этот шаг стоил 3 426 долларов в кредитах API.

Затем агенты-аналитики изучили каждый объект аудита и выявили потенциальные уязвимости, используя процесс, похожий на тот, что применяется в плагине Codex Security⁠(открывается в новом окне). В общих чертах агенты-аналитики изучают код назначенного им объекта аудита, чтобы понять, как он работает, определить модель угроз и найти в нём уязвимости.

За 12 часов агенты-аналитики выявили 2 308 потенциальных уязвимостей после удаления дубликатов. Этот этап стоил 316 549 долларов в кредитах API.

Потенциальная уязвимость — не то же самое, что подтверждённая. При таком масштабе наша исследовательская команда не может вручную разбирать каждый отчёт.

Поэтому мы сосредоточились на проверке находок, которые а) были доступны пользователю с низкими привилегиями, б) не требовали специальных разрешений и в) давали измеримые свидетельства повреждения памяти.

Для каждой потенциальной уязвимости агент проверки создавал PoC и запускал его в изолированной виртуальной машине с ядром Linux и Kernel Address Sanitizer (KASAN). Агент отслеживал вывод программы и системной консоли, затем итеративно дорабатывал PoC, пока не воспроизводил описанное поведение или не исчерпывал возможные способы его вызвать.

За 30 часов наша система воспроизвела 1 724 уязвимости — около 74,7 % из 2 308 потенциальных. Один лишь статический анализ кода может давать ложноположительные результаты, поэтому нас впечатлили точность агентов-аналитиков и эффективность агентов проверки: они самостоятельно создали работающие PoC почти для трёх четвертей потенциальных уязвимостей.

Большинство оставшихся находок либо требовали повышенных привилегий, либо не удалось воспроизвести за отведённое время из-за сложных состояний гонки, особых условий срабатывания — например, отказа выделения памяти на конкретной строке — или длительной проверки, как в случае переполнения счётчика ссылок. Лишь 3,1 % были следствием ошибочного анализа модели, когда заявленная уязвимость предполагала невозможное условие.

Общие затраты на этап проверки составили 73 330 долларов в кредитах API. Мы заметили, что в нашем конвейере проверки создание PoC для подтверждения реальности потенциальной уязвимости обходилось дороже, чем рекомендация на основе одного лишь статического анализа. При этом затраты на попытку проверить истинноположительный и ложноположительный результаты были сопоставимы. Таким образом, отсеивание ложноположительных результатов на ранних этапах конвейера заметно повышает экономическую эффективность процесса.

Проверка подтверждает, что уязвимость реальна, но не определяет, насколько срочно её нужно устранить. Например, уязвимость, позволяющая локально повысить привилегии, заслуживает более высокого приоритета, чем та, которая может вызвать лишь локальный отказ в обслуживании. После подтверждения 1 724 уязвимостей следующей задачей было определить, какие из них потенциально представляют наибольшую угрозу безопасности.

Агент предварительного отбора проводил статический анализ каждого отчёта, журнала сбоя и соответствующего исходного кода. Его критерии намеренно были мягкими, чтобы не отсеять потенциально серьёзные находки, но исключить случаи без правдоподобного пути эксплуатации. Это сузило выборку до 313 потенциальных утечек информации и 1 238 потенциальных уязвимостей локального повышения привилегий.

Затем агенты разработки эксплойтов (ExploitDev) проверили эти находки в изолированных виртуальных машинах с включёнными защитными механизмами стандартного дистрибутива Linux: запретом выполнения кода в режиме супервизора (SMEP), запретом доступа в режиме супервизора (SMAP), рандомизацией размещения адресного пространства ядра (KASLR) и HARDENED_USERCOPY. Это помогло избежать нереалистичных оценок, основанных на отключённых механизмах защиты.

Агенты создали 291 PoC утечки информации и 1 169 работающих эксплойтов локального повышения привилегий, способных дать непривилегированным локальным пользователям root-доступ.

Мы провели анализ вариантов уязвимостей и разработали 948 отдельных патчей для уязвимостей, лежащих в основе этих эксплойтов. Именно это число мы используем как общее количество уникальных LPE-уязвимостей. Разработка успешного эксплойта обходилась в среднем в 359 долларов в кредитах. Таким образом, специалисты по защите могут проверять возможность эксплуатации найденных уязвимостей при сравнительно небольших затратах.

Работа агента предварительного отбора уязвимостей стоила 44 194 доллара в кредитах API. Общие затраты на этап эксплуатации составили 775 929 долларов в кредитах API: 84 929 долларов на проверку потенциальных утечек информации и 691 000 долларов на потенциальные уязвимости локального повышения привилегий.

В среднем работа с потенциальной уязвимостью локального повышения привилегий (558 долларов) обходилась примерно вдвое дороже, чем с потенциальной утечкой информации (271 доллар). Причина в том, что PoC утечек информации переходили с этапа проверки и требовали меньшей доработки для использования в эксплойте. Напротив, разработка эксплойта для потенциальной LPE-уязвимости требовала множества дополнительных шагов: планирования стратегии эксплуатации, выбора уязвимых объектов, обхода механизмов защиты и других. Мы также заметили, что неудачные попытки эксплуатации обходились значительно дороже успешных: 3 922 доллара для 69 случаев против 360 долларов для 1 169 случаев. Это было связано с несколькими сложными для эксплуатации уязвимостями, например состояниями гонки. Разумное условие прекращения попыток — например, остановка после часа без прогресса — позволило бы существенно сократить затраты на ExploitDev.

Для каждой подтверждённой уязвимости система также генерирует патч. Мы предоставляем модели соответствующий исходный код и инструкции по лучшим практикам написания патчей: проводить статические проверки патча, следовать подходам к разработке, принятым в соседнем коде, и анализировать варианты уязвимости, чтобы убедиться в полноте исправления.

Следуя рекомендации сообщества ядра Linux, мы уже отправили сотни отчётов и патчей для критических уязвимостей и работаем с партнёрами Patch the Planet, чтобы постепенно отправить патчи для остальных. Эта работа — часть наших более широких обязательств по поддержке проектов с открытым исходным кодом в рамках Daybreak.

В этом разделе мы делимся выводами, наблюдениями и дополнительным анализом результатов исследования.

В ходе исследования мы наблюдали, как быстро мейнтейнеры Linux устраняют уязвимости и защищают пользователей. Сканирование проводилось на последней версии ядра Linux в середине октября 2026 года. Когда через 10 дней автономное сканирование и ручной анализ завершились, 61 LPE-уязвимость уже была исправлена в основном проекте, для 43 были подготовлены патчи, а ещё о 299 сообщалось и велись публичные обсуждения.

Мы очень благодарны мейнтейнерам Linux, которые оперативно исправляют выявленные проблемы, а также всему сообществу специалистов по безопасности, которое делится своими находками. Именно такие совместные усилия нужны для обеспечения безопасности ПО во всём мире. Высокий темп раскрытия и исправления уязвимостей также подчёркивает, насколько важно пользователям и компаниям своевременно обновлять ПО.

Вывод: автоматическая проверка и приоритизация уязвимостей должны учитывать быстрый цикл выпуска исправлений. Повторная проверка находок на актуальном коде, включая изменения, внесённые после исходного сканирования, помогает избежать дублирующих или устаревших отчётов. Это позволяет сосредоточиться на неустранённых уязвимостях и даёт мейнтейнерам данные, на основе которых можно действовать, не создавая лишней нагрузки по проверке отчётов.

В конце июля 2026 года, пока мы разрабатывали конвейер, GPT‑5.6 Sol нашла и проэксплуатировала 166 уникальных LPE-уязвимостей. Общие затраты составили 513 690 долларов в кредитах API.

Во время второго сканирования, в середине октября 2026 года, более новая модель для кибербезопасности нашла и проэксплуатировала 948 уникальных LPE-уязвимостей. Общие затраты составили 1 213 430 долларов в кредитах API. В обоих случаях мы сканировали актуальную на тот момент ветку master ядра Linux.

Вывод: по мере роста возможностей моделей повторно сканируйте код, уже прошедший аудит. Более мощная модель может обнаружить уязвимости, которые пропустили предыдущие модели, даже при использовании той же исследовательской обвязки.

Мы отобрали 166 эксплойтов, разработанных агентами, и проанализировали использованные в них техники эксплуатации. Насколько нам известно, в этой выборке агенты использовали 10 новых техник эксплуатации. Мы показали эти техники сторонним экспертам по эксплуатации уязвимостей ядра, и для них они тоже оказались новыми.

Из 10 техник две используют новые долгоживущие объекты переменного размера, с помощью которых модель массово размещала объекты в целевом кэше ядра; ещё две — новые способы подготовки страниц памяти для повышения надёжности эксплойта; пять — новые техники, воздействующие только на данные и позволяющие повысить привилегии напрямую или через произвольную запись; последняя техника связана с произвольным смешением типов. Из соображений безопасности мы не раскрываем в этой публикации полные технические подробности новых техник эксплуатации.

Вывод: передовые модели не просто распознают известные шаблоны уязвимого кода и не ограничиваются известными техниками эксплуатации — они проявляют изобретательность и находят новые подходы.

Важная часть миссии нашей команды — измерять затраты на поиск и эксплуатацию уязвимостей и использовать эти данные для определения приоритетов вложений в защиту. Наша цель — помочь специалистам по защите исправлять уязвимости раньше, чем ими воспользуются злоумышленники, и сделать эксплуатацию уязвимостей ПО непомерно дорогой для атакующих. Измерение затрат на эксплуатацию помогает оценить, как эта задача меняется по мере роста возможностей моделей. В этом разделе мы сравниваем стоимость запуска нашего конвейера с вознаграждениями за выявленные уязвимости в программах bug bounty.

Целевые виртуальные машины в нашем эксперименте работали под управлением стандартной настольной ОС, без искусственного ослабления защиты, с той же моделью угроз, что используется на соревнованиях по кибербезопасности, например Pwn2Own⁠(открывается в новом окне) и TyphoonPWN⁠(открывается в новом окне). Ранее Pwn2Own и TyphoonPWN предлагали вознаграждения в размере 20 000 и 70 000 долларов соответственно за эксплойты локального повышения привилегий в ядре Linux. Если применить эти прежние размеры вознаграждений к 948 эксплойтам, их гипотетическая оценка составит 18,9–66,3 млн долларов — примерно в 16–55 раз больше затрат на наш конвейер.

Мы также протестировали конвейер в условиях программы вознаграждений Google kernelCTF⁠(открывается в новом окне), где целью служит ядро Linux с усиленной защитой и сокращённой поверхностью атаки. Мы запустили конвейер на последней версии ядра Linux в среде kernelCTF и получили 25 PoC утечек информации и 21 эксплойт локального повышения привилегий. Эта версия ядра несовместима с защитой SLAB_VIRTUAL в kernelCTF, поэтому мы исключили её из конфигурации. Для сравнения: на момент написания статьи в 2026 году программа kernelCTF приняла 26 подтверждённых LPE-эксплойтов для уязвимостей нулевого дня. Весь цикл исследования занял 112 часов и стоил около 32 936 долларов в кредитах API, причём на поиск уязвимостей пришлось 83,7 % затрат на API. Если бы программа приняла эту 21 уязвимость, вознаграждение составило бы около 1,5 млн долларов — примерно в 45 раз больше затрат.

Вывод: исходя из публично известных размеров выплат, на момент исследования наш конвейер поиска уязвимостей с текущими моделями, способными решать задачи кибербезопасности, был рентабельным. Специалистам по защите следует заблаговременно анализировать своё ПО, чтобы сделать эксплуатацию его уязвимостей непомерно дорогой для злоумышленников.

На этапе оценки возможности эксплуатации агенты ExploitDev получали отчёт об уязвимости и задание создать полностью работающий эксплойт. Наш конвейер отмечал уязвимость как успешно проэксплуатированную, если удавалось получить командную оболочку с правами root. Во время одного из ранних запусков этап эксплуатации выдал 200 успешных эксплойтов локального повышения привилегий. Однако после проверки специалистами выяснилось, что 20 из них получили права root через другую уязвимость нулевого дня, а не через назначенную. Это показывает, что даже успешная эксплуатация уязвимости агентом требует надлежащей проверки.

После этого мы ужесточили ограничения задачи и добавили независимую проверку того, что каждый итоговый эксплойт использует именно назначенную ему уязвимость.

Вывод: в автономных исследованиях безопасности нужно проверять не только результат, но и путь к нему; изоляция, мониторинг и независимые проверки — необходимые меры контроля.

В начале исследования мы изучали, стоит ли создавать вокруг агента сложную систему оркестрации, чтобы расширить его возможности в области кибербезопасности. Результаты показали, что более мощным моделям требуется менее сложная оркестрация и меньше подсказок. При этом небольшой прирост качества не оправдывает затрат на поддержку. В итоге мы решили отказаться от сложной оркестрации.

В эксперименте сравнивались GPT‑5.5 Cyber и GPT‑5.6 Cyber. По нашим наблюдениям, GPT‑5.5 Cyber не всегда верно определяла, когда и как применять существующие техники эксплуатации уязвимостей ядра Linux. Тогда мы собрали 103 техники в удобном для модели формате, разместили их в среде агента и дали ему указание использовать их. На выборке из 63 потенциально эксплуатируемых уязвимостей это повысило долю успеха с 76,2 % до 88,9 %.

Повторив эксперимент с GPT‑5.6 Cyber, мы увидели, что эта модель лучше самостоятельно находит, выбирает и применяет подходящие техники. Мы убрали оркестрацию техник и навыков, и процесс на базе GPT‑5.6 Cyber с упрощённой оркестрацией превзошёл процесс на базе GPT‑5.5 Cyber с более сложной системой поддержки. Возвращение дополнительного слоя техник для GPT‑5.6 Cyber дало лишь небольшой прирост — 1,5 процентного пункта.

Вывод: пересматривайте оркестрацию и обвязку по мере изменения возможностей базовых моделей. Вспомогательные механизмы, которые заметно улучшают работу одного поколения моделей, могут почти не приносить пользы более мощной модели. Их ценность следует сопоставлять с затратами на поддержку.

Сначала по прямому запросу на генерацию патчей модель создавала функционально корректные исправления, блокирующие PoC, но иногда вносила другие проблемы: добавляла лишний код, потенциально снижала производительность, отклонялась от соглашений о стиле кода или не проверяла связанный код на варианты той же уязвимости, из-за чего исправления оставались неполными.

Дополнительные инструкции и итеративная доработка процесса генерации повысили качество патчей. Это говорит о том, что при правильном подходе созданные ИИ патчи безопасности могут быть корректными, минимальными и соответствовать существующим соглашениям о стиле кода. Исследования в этой области активно продолжаются, и мы полагаем, что с будущими моделями процесс станет проще и эффективнее. В нескольких случаях наш исследовательский прототип также выявил проблемы в патчах, написанных экспертами. Их исправили до включения патчей в основной код.

Вывод: модели могут ускорить выпуск исправлений, но навыки создания патчей и обвязки могут требовать итеративной доработки, чтобы патчи надёжно выполняли как функциональные, так и нефункциональные требования. Кроме того, мы рекомендуем использовать модели для проверки патчей, созданных людьми и ИИ, с позиции атакующего. Это позволяет выявлять возможность обхода исправления, пропущенные пути и варианты атак и другие проблемы.

Во время запуска в kernelCTF, помимо 21 эксплойта для уязвимостей нулевого дня в ядре Linux, наш исследовательский прототип также нашёл и проэксплуатировал уязвимость QEMU TCG. Агенту-аналитику поручили изучить код входа в системные вызовы. При написании программ для экспериментов с переходами между уровнями привилегий он столкнулся с неожиданным сбоем ядра. Он разобрал сбой и установил, что проблема находится в QEMU TCG, не имея доступа к исходному коду QEMU, а затем включил уязвимость в отчёт. Впоследствии агент ExploitDev успешно разработал для этой уязвимости эксплойт локального повышения привилегий. Мы обнаружили эту уязвимость QEMU при ручном анализе эксплойтов и подтвердили, что она уже исправлена в основном проекте QEMU, но не в релизной сборке, использованной в эксперименте.

Вывод: передовые модели с возможностями в области кибербезопасности способны находить уязвимости в тестовой инфраструктуре. Мы рекомендуем проверять каждый компонент инфраструктуры перед исследованием уязвимостей с применением атакующих методов. Мы заблаговременно протестировали нашу инфраструктуру, раскрыв и исправив множество уязвимостей в Kata, Moby/Docker, gVisor и других проектах.

Наша цель — превратить растущие возможности моделей в устойчивое преимущество для тех, кто обеспечивает безопасность интернета. Это исследование показывает, что растущие возможности передовых моделей в области кибербезопасности можно использовать для эффективного поиска уязвимостей в сложном ПО, таком как ядро Linux. Укрепление защиты критически важных программных проектов, таких как Linux и другие проекты с открытым исходным кодом, позволяет защитить множество использующих их систем и пользователей.

В рамках Patch the Planet, одной из инициатив Daybreak, мы намерены распространить это исследование на другие критически важные программные проекты и совместно с мейнтейнерами и партнёрами по безопасности разработать надёжные средства автоматического исправления уязвимостей. Мы хотим последовательно сокращать возможности злоумышленников и повышать затраты на поиск и эксплуатацию уязвимостей до тех пор, пока ожидаемая выгода не перестанет оправдывать атаку.

Каждое поколение моделей должно помогать нам создавать ПО, которое следующему поколению будет сложнее взломать. Мы продолжим работать над безопасным интернетом, в котором каждый сможет с удовольствием создавать что-то новое.