Branch Target Reuse: нова загроза Spectre v2 для JIT і ядра

Дослідники представили новий варіант атаки класу 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 (ускладнює пряме керування константами в згенерованому коді).

У першому варіанті експлуатується проста послідовність:

зловмисник завантажує першу cBPF-програму, завдання якої — «натренувати» передбачувач переходів на конкретний шаблон непрямих переходів;
цю програму видаляють, звільняючи пам’ять із кодом;
у тому самому діапазоні адрес розміщується друга cBPF-програма, спроєктована для витоку даних через побічний канал;
передбачувач переходів усе ще зберігає ціль непрямого переходу першої програми, і 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 у недовірених контекстах і переглянути архітектуру ізоляції там, де на одному «залізі» співіснують різні домени довіри.