Две недели назад мы объявили, что с помощью Claude Mythos Preview и других AI-моделей нашли и исправили рекордное количество скрытых уязвимостей в Firefox. В этом посте — подробности о подходе, результатах и советы для других проектов, которые хотят применять эти техники.
Баги резко стали качественнее
Ещё несколько месяцев назад AI-сгенерированные отчёты о безопасности в open source были преимущественно мусором. Отвечать на отчёты, которые выглядят правдоподобно, но ошибочны, — асимметричная нагрузка: сгенерировать «проблему» дёшево, а разобраться в ней — дорого.
Сложно переоценить, насколько сильно эта картина изменилась за несколько месяцев. Два фактора сыграли роль одновременно: модели стали значительно мощнее, и мы кардинально улучшили техники управления ими.
Обычно подробные отчёты о багах остаются закрытыми несколько месяцев после выпуска исправлений и публикации security advisories — как мера защиты пользователей, которые медленно обновляются. Учитывая огромный интерес к теме и срочность происходящего в экосистеме, мы решили раскрыть небольшую выборку отчётов, стоящих за недавно выпущенными патчами. Мы постарались охватить разные подсистемы браузера, хотя выборка и остаётся несколько произвольной. Тем не менее глубина и разнообразие этих отчётов подкрепляет оценку возможностей и призыв к защитникам начать применять эти техники:
ID бага | Описание |
|---|---|
Некорректная проверка равенства позволяет JIT оптимизировать инициализацию живой WebAssembly GC-структуры, создавая примитив fake-object с потенциальным произвольным чтением/записью в коде, который прошёл интенсивный фаззинг внутренними и внешними исследователями. | |
15-летний баг в элементе | |
Надёжная эксплуатация race condition через IPC: скомпрометированный content process манипулирует refcount'ами IndexedDB в parent, провоцируя UAF и потенциальный sandbox escape. | |
Сырое значение NaN, пересекающее границу IPC, может маскироваться под tagged JS-указатель на объект. Двойная десериализация превращается в примитив fake-object в parent process для sandbox escape. | |
Изощрённый тест-кейс, проходящий через вложенные event loop, pagehide-листенеры и сборщик мусора, провоцирует UAF в атрибут-сеттере элемента | |
Инициирует UAF в parent-процессе через флуд WebTransport тысячами хешей сертификатов для растягивания race condition в refcount-тяжёлом цикле копирования; используется через IPC из скомпрометированного content process. | |
Эмулирует вредоносный DNS-сервер, перехватывая вызовы DNS-функций glibc, чтобы воспроизвести краевой случай UDP→TCP fallback, провоцирующий buffer over-read и утечку стековой памяти parent process при парсинге HTTPS RR и ECH. | |
20-летний баг в XSLT: реентерабельные вызовы | |
Патчит color picker для имитации иначе не автоматизируемого выбора пользователем, затем использует синхронный input event для раскрутки вложенного event loop, повторно входящего в actor teardown и освобождающего callback при его исполнении — UAF в content process. | |
Скомпрометированный content process мог отправить произвольное изображение для декодирования в parent process; это можно было скомбинировать с гипотетической уязвимостью в декодере изображений для побега из sandbox. Потребовалось трудно автоматизируемое рассуждение об уровне доверия входных данных в parent process. | |
Побег из нашей технологии внутрипроцессного изолирования для сторонних библиотек (RLBox) через пробел в логике верификации при копировании значений из недоверенной части sandbox в доверенную. | |
Минимальный тест-кейс, эксплуатирующий специальную семантику |
Ряд багов — это sandbox escapes, которые требуют комбинации с другими эксплойтами для полной компрометации Firefox. В этих отчётах предполагается, что изолированный процесс рендеринга уже скомпрометирован каким-то отдельным багом и выполняет управляемый атакующим машинный код, пытаясь повысить привилегии до уровня родительского процесса. При построении sandbox escape модели разрешено патчить исходный код Firefox — при условии, что изменённый код исполняется только в изолированном процессе. Такие баги традиционно крайне сложно обнаружить фаззингом, и хотя мы разрабатывали новые техники, AI-анализ обеспечивает значительно более полное покрытие этой критической поверхности.
Не менее интересно то, чего модели не нашли — не потому что не пытались, а потому что не смогли обойти эшелонированную защиту Firefox. Например, несколько лет назад мы получали отчёты от исследователей, которым удавалось сбежать из sandbox, провоцируя prototype pollution в привилегированном parent process. Вместо того чтобы чинить эти проблемы по одной, мы сделали архитектурное изменение, заморозив эти прототипы по умолчанию. Изучая логи харнесса, мы видели многочисленные попытки использовать этот вектор, заблокированные этим решением. Наблюдать прямую отдачу от прошлых решений по укреплению было даже приятнее, чем находить и чинить новые баги.
Построение пайплайна на основе моделей
На протяжении нескольких лет мы экспериментировали с аудитом кода через LLM: ранние попытки с GPT-4 и Sonnet 3.5 для статического анализа рискованного кода показывали определённый потенциал, но высокий процент ложных срабатываний делал масштабирование нецелесообразным.
Появление агентных харнессов, способных надёжно обнаруживать проблемы безопасности, полностью изменило ситуацию. Они находят реальные баги и отбрасывают невоспроизводимые предположения. Ключевое свойство такого харнесса: при наличии правильных интерфейсов и инструкций он создаёт и запускает воспроизводимые тест-кейсы для динамической проверки гипотез о багах в коде. После исправления первоначального набора проблем, присланных нам Anthropic в феврале, мы создали собственный харнесс поверх существующей инфраструктуры фаззинга.
Начинали с небольших экспериментов, направляя харнесс на поиск sandbox escape с Claude Opus 4.6. Уже с этой моделью мы нашли впечатляющее количество ранее неизвестных уязвимостей, требовавших сложного рассуждения о коде многопроцессного движка браузера. Поначалу мы наблюдали за процессом в терминале в реальном времени, настраивая промпты и логику. После отладки распараллелили задачи на несколько эфемерных VM, каждая из которых искала баги в конкретном целевом файле и записывала результаты в бакет.
Подсистема обнаружения — необходимое, но недостаточное условие. Для масштабирования потребовалась интеграция с полным жизненным циклом security-багов: определение, что искать, где искать и что делать с результатами. Последнее включает дедупликацию против известных проблем, трекинг, триаж, отправку фиксов. Модель — ядро харнесса, но весь пайплайн необходим для работы в масштабе.
Харнессы могут быть переиспользованы между проектами, но пайплайн по своей природе специфичен для каждого проекта — он отражает семантику, инструментарий и процессы конкретной кодовой базы. Его построение потребовало значительных итераций в тесной связке с Firefox-инженерами, которые разбирали входящие баги.
Обновление моделей
После того как сквозной пайплайн выстроен, замена моделей по мере их появления становится тривиальной задачей. Раннее построение пайплайна помогло нам найти серьёзные баги на общедоступных моделях и дало возможность сразу запустить оценку Claude Mythos Preview. По нашему опыту, обновление модели повышает эффективность всего пайплайна одновременно: система лучше находит потенциальные баги, создаёт proof-of-concept тест-кейсы и формулирует патологию и влияние найденного.
Помимо исправления 271 бага, обнаруженного Claude Mythos Preview в релизе 150, мы выпустили дополнительные фиксы в 149.0.2 и 150.0.1. Внутренний поиск багов другими методами продолжается, и мы видим заметный рост числа внешних отчётов за последние несколько месяцев.
В конечном счёте каждый баг требует тщательной работы для правильного исправления. Справляться с беспрецедентным объёмом оказалось непросто — последние несколько месяцев команда работала с большой нагрузкой. Более 100 человек внесли вклад в код: писали и ревьюили патчи, строили и масштабировали пайплайн, делали триаж, тестировали исправления, управляли процессом релизов.
Выводы
Любой разработчик ПО уже сегодня может запустить харнесс с современной моделью для поиска багов и укрепления своего кода. Рекомендуем начать прямо сейчас. Вы найдёте баги и будете готовы использовать новые модели по мере их появления.
Начать можно с простейших промптов, наблюдать и итерировать. Наши начальные промпты были похожи на те, что описаны здесь. В процессе итераций мы построили оркестровку и инструментарий для оптимизации и масштабирования, но суть внутреннего цикла осталась прежней: в этом фрагменте кода есть баг — найди его и построй тест-кейс.
Сейчас сканирование сосредоточено на конкретных участках кода (файлах, функциях), которые мы указываем системе на основе сочетания экспертного суждения и автоматических сигналов. В ближайшем будущем мы намерены интегрировать этот анализ в систему CI для сканирования патчей при их добавлении в дерево. Модели достаточно гибки в отношении формы предоставляемого контекста, и мы ожидаем, что сканирование на основе патчей будет работать не хуже файлового, а возможно, и лучше.
Русскоязычное сообщество про AI в разработке
Друзья! Перевод этой статьи подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-агентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!
FAQ
1. В заголовке говорилось о «271 баге», но я считаю иначе. В чём дело?
На странице advisories все внутренне обнаруженные баги группируются в «сводные» CVE с несколькими багами под каждым. Страница строится на основе yaml в репозитории foundation-security-advisories — это каноническое место для CVE-назначений. В Firefox 150 было три внутренних сводки: CVE-2026-6784 (154 бага), CVE-2026-6785 (55 багов) и CVE-2026-6786 (107 багов).
Сумма — 316, а не 271. Разница объясняется тем, что команда безопасности ежедневно ищет новые баги несколькими методами: (а) системы фаззинга, (б) ручной анализ, (в) новый агентный пайплайн на разных моделях.
Всего в апреле мы исправили 423 security-бага. В дополнение к 271 багу из объявления было 41 из внешних отчётов; оставшиеся 111 примерно поровну распределились между: багами Claude Mythos Preview, исправленными в других релизах; багами, найденными пайплайном с другими моделями; и багами из других техник, включая фаззинг.
Отдельно мы напрямую атрибутировали Anthropic 3 CVE (CVE-2026-6746, CVE-2026-6757, CVE-2026-6758) — это исправления для багов, присланных нам командой Anthropic Frontier Red несколько месяцев назад.
2. Что означают рейтинги безопасности?
Мы применяем рейтинги серьёзности от critical до low. sec-critical и sec-high присваиваются уязвимостям, воспроизводимым при обычном поведении пользователя (например, переходе на веб-страницу); технического различия между ними нет, но sec-critical зарезервирован для публично раскрытых или эксплуатируемых в реальных атаках проблем. sec-moderate — то, что иначе было бы sec-high, но требует необычных и сложных действий от жертвы. sec-low — баги, далёкие от реального вреда пользователю.
Из 271 бага для Firefox 150: 180 — sec-high, 80 — sec-moderate, 11 — sec-low.
3. Является ли sec-high или sec-critical баг готовым эксплойтом?
Не обязательно. В большинстве случаев одного критического/высокого бага недостаточно для компрометации Firefox из-за эшелонированной архитектуры защиты: например, эксплуатация JIT-бага даёт выполнение кода только в изолированном и сайт-специфичном процессе. Реальным атакующим нужно выстраивать цепочку из нескольких эксплойтов для повышения привилегий через слои изоляции и OS-митигаций вроде ASLR.
Готовые эксплойты мы обычно не строим. Классификация sec-high основана на предсказуемых симптомах краша — use-after-free или out-of-bounds обращения к памяти, фиксируемые AddressSanitizer. Наша threat model предполагает, что любой из них может быть эксплуатирован при достаточных усилиях.