Branch Target Reuse: как новая разновидность Spectre v2 бьет по JIT, ядру Linux и песочницам

Исследователи представили новый вариант атаки класса Spectre v2, получивший название Branch Target Reuse (BTR), который затрагивает процессоры Intel, AMD и Arm и позволяет через движки JIT и ядро Linux извлекать секреты из памяти вплоть до хеша пароля root за несколько минут. Уязвимые — любые среды, где недоверенный код может запускать JIT или использовать фильтры/программы в ядре (например, cBPF), а защита требует обновления ядра Linux (CVE-2026-64507, CVE-2026-64508), настройки аппаратных барьеров предсказателя ветвлений и пересмотра политики использования JIT в изолированных средах.

Технические детали атаки Branch Target Reuse

Атака BTR описана исследователями из VUSec и Scuola Superiore Sant’Anna и подробно разобрана на странице проекта Branch Target Reuse. По сути, это развитие Spectre v2: злоумышленник не только отравляет предсказатель косвенных переходов, но и использует тот факт, что состояние предсказателя живет дольше, чем соответствующий машинный код в памяти.

Ключевой механизм:

• косвенные переходы (indirect branch) запоминаются в предсказателе ветвлений вместе с целью перехода;
• JIT или ядро освобождают страницу с кодом и затем используют тот же адрес памяти под новый код;
• предсказатель продолжает хранить «старую» цель перехода, относящуюся к уже освобожденному коду;
• процессор при выполнении нового кода может спекулятивно перейти по устаревшей цели и выполнить фрагмент, выгодный атакующему.

Авторы характеризуют это как «спекулятивный execute-after-free» для кода: даже после освобождения и повторного использования памяти ветвление продолжает спекулятивно целиться в старый фрагмент, пока предсказатель не будет очищен.

Эксплуатация через cBPF в ядре Linux

Практический сценарий исследователи продемонстрировали на JIT-компиляции классического BPF (cBPF) в ядре Linux. Движок JIT в ядре генерирует машинный код фильтров в память и может затем освобождать/повторно использовать те же страницы – идеальные условия для BTR.

Разработано два proof-of-concept эксплоита для Linux:

• для конфигурации ядра по умолчанию;
• для конфигурации с включенной защитой constant blinding (затрудняет прямое управление константами в сгенерированном коде).

В первом варианте эксплуатируется простая последовательность:

1. злоумышленник загружает первую cBPF-программу, задача которой — «обучить» предсказатель ветвлений конкретному шаблону косвенных переходов;
2. эта программа удаляется, высвобождая память с кодом;
3. в том же адресном диапазоне размещается вторая cBPF-программа, спроектированная для утечки данных через побочный канал;
4. предсказатель ветвлений все еще хранит цель косвенного перехода первой программы, и CPU спекулятивно исполняет полезный для атакующего фрагмент второй программы.

Этого достаточно, чтобы читать произвольную память со скоростью порядка 8 байт в секунду. В демонстрации исследователи находили процесс su и извлекали из его памяти хеш пароля root, затрачивая на атаку считанные минуты.

Во втором варианте эксплоита, на системе с включенным constant blinding, исследователи кодировали управляемые инструкции в смещениях переходов. Несмотря на усложнение, хеш пароля root также удавалось извлечь менее чем за пять минут. На процессорах архитектур Raptor Cove и Lion Cove среднее время атаки составило около трех и пяти минут соответственно.

Связанные с этим проблемы ядра Linux получили идентификаторы CVE-2026-64507 и CVE-2026-64508. Описание уязвимостей доступно как в рассылке Linux CVE-2026-64507 и CVE-2026-64508, так и в базе NVD: CVE-2026-64507 в NVD, CVE-2026-64508 в NVD.

Попытки атаковать SpiderMonkey и GraalVM

BTR также протестирована против движков JIT более высокого уровня:

• SpiderMonkey (движок JavaScript в Firefox) — устаревшие предсказания действительно «переживали» повторное использование памяти, что подтверждает фундаментальность эффекта. Однако создать полноценный браузерный эксплоит не удалось: мешают дополнительные механизмы защиты и сложная внутренняя динамика браузера.
• Oracle GraalVM — исследователям удалось спекулятивно обойти механизм маскирования адресов памяти, который как раз предназначен для защиты песочницы от атак, похожих на Spectre. Тем не менее до рабочей атаки не дошло: фоновая активность GraalVM слишком быстро очищала записи предсказателя.

Ключевой вывод: эффект Branch Target Reuse воспроизводится на всех протестированных процессорах Intel, AMD и Arm и проявляется в различных типах JIT, даже если их собственные внутренние защиты достаточно агрессивны.

Аппаратный барьер Indirect Branch Predictor Barrier (IBPB), описанный в руководстве Intel Software Security Guidance: Indirect Branch Predictor Barrier, затрудняет эксплуатацию BTR, но за счет ощутимой потери производительности.

Контекст угроз: место BTR в семействе Spectre

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

Важные следствия:

• любая платформа, где недоверенный код может инициировать генерацию и выгрузку кода JIT, потенциально подвержена: браузеры, виртуальные машины Java, .NET, GraalVM, движки смарт-контрактов, движки регулярных выражений в базе данных и так далее;
• ядро ОС — не исключение: JIT в подсистемах фильтрации пакетов (cBPF, eBPF) превращается в еще один канал утечки межпроцессных секретов;
• классические границы «процесс — адресное пространство» ослабевают: атакующий с низкими привилегиями может вычитать данные процесса с более высокими привилегиями или ядра, минуя прямые ошибки доступа памяти.

Исследование не приводит примеров эксплуатации в дикой природе и не связывает BTR с конкретными злоумышленниками или операциями, однако опыт развития Spectre и Meltdown показывает, что по мере упрощения и оптимизации техник подобные атаки постепенно переходят в арсенал продвинутых групп.

Оценка воздействия на организации и инфраструктуру

Наибольший риск BTR создает в сценариях совместного использования ресурсов и сложной изоляции:

• серверы общего назначения и виртуализация — особенно в средах, где контейнеры или виртуальные машины клиентов могут загружать собственные фильтры или программы в подсистемы BPF ядра;
• рабочие станции разработчиков и системы с активным использованием GraalVM, JVM и других интенсивных JIT — повышенная вероятность локального злоупотребления внутри одной машины;
• корпоративные браузеры — при массовом использовании Firefox важна завершенность режима изоляции сайтов, снижающего ценность кросс-сайтовых сторонних каналов;
• системы с высокочувствительными секретами в памяти (ключи шифрования, токены доступа, административные пароли) — даже медленный канал утечки в несколько байт в секунду опасен.

Если не предпринимать действий, возможные последствия включают:

• извлечение хешей паролей привилегированных учетных записей и последующий офлайн-взлом паролей;
• кражу криптографических ключей, токенов доступа и других долгоживущих секретов из процессов приложений или служб;
• незаметное ослабление моделей доверия «низкопривилегированный код — высокопривилегированные данные», в том числе внутри песочниц и контейнеров;
• регуляторные риски, если утечка затронет данные, подпадающие под отраслевые или государственные требования.

Практические рекомендации по защите

1. Обновление ядра Linux

Проблемы, описанные в CVE-2026-64507 и CVE-2026-64508, уже исправлены в ядре Linux. Рекомендуемые шаги:

• убедиться, что используемый дистрибутив включил патчи для указанных CVE;
• проверить наличие записей об этих уязвимостях в бюллетенях поставщика и в NVD: CVE-2026-64507, CVE-2026-64508;
• приоритизировать обновление серверов, где доступны подсистемы BPF для непривилегированных пользователей.

До обновления целесообразно:

• ограничить право загрузки программ BPF только для административных учетных записей;
• оценить возможность временного отключения JIT для cBPF/eBPF в высокочувствительных средах, если это допустимо для нагрузок.

2. Использование аппаратных барьеров предсказателя

В высокорисковых сегментах (серверы с несколькими уровнями доверия, системы обработки секретных данных) рассмотрите включение механизмов, подобных IBPB. Руководство Intel по IBPB доступно по ссылке Indirect Branch Predictor Barrier.

Практический подход:

• включать IBPB только для процессов с разными доменами доверия (например, при переключении с недоверенного клиента на процесс, работающий с секторальными или государственными данными);
• тестировать влияние на производительность под типичными рабочими нагрузками до массового включения.

3. Управление JIT и изоляцией в пользовательском пространстве

• для браузеров Firefox обеспечить использование последних версий с завершенной изоляцией сайтов, что снижает ценность потенциальных сторонних каналов между вкладками;
• в средах с GraalVM и другими виртуальными машинами Java установить обновления от Oracle и следовать их рекомендациям по защите от Spectre-подобных атак;
• пересмотреть политику включения JIT в сценариях, где допустима его деактивация (например, специализированные серверные инстансы без необходимости максимальной производительности скриптов).

4. Мониторинг и операционные меры

Хотя атаки по сторонним каналам трудно детектировать напрямую, можно контролировать вспомогательные признаки:

• необычные шаблоны загрузки и выгрузки программ BPF ядра, особенно от непривилегированных пользователей;
• аномальное использование утилит повышения привилегий (вроде su) на серверах приложений;
• генерацию и частое обновление большого числа программ JIT в недоверенных контекстах.

В стратегическом плане BTR — повод усилить сегментацию: самые критичные секреты лучше хранить на системах, где недоверенный код (включая клиентские контейнеры и рантаймы с JIT) вообще не выполняется.

BTR демонстрирует, что класс Spectre v2 остается живым даже после нескольких волн защит, а предсказатели ветвлений современных процессоров фундаментально не успевают за динамикой JIT и ядра. На практике сейчас важно: обновить ядро Linux до версий с исправлениями для CVE-2026-64507 и CVE-2026-64508, по возможности включить аппаратные барьеры предсказателя для критичных узлов, ограничить использование JIT и BPF в недоверенных контекстах и пересмотреть архитектуру изоляции там, где на одном «железе» сосуществуют разные домены доверия.