Атака BTR, новый вариант Spectre v2, в тестах позволила извлечь хеш root-пароля из памяти Linux-системы на процессорах Intel в среднем за 3-5 минут. Для русскоязычных команд это не повод панически выдёргивать серверы из стоек, но хороший сигнал: обновления ядра и микрокода снова становятся не скучной гигиеной, а прямой защитой от вполне практичных атак на уровне CPU.
О новом методе сообщает BleepingComputer. Исследователи из VUsec, группы Systems and Network Security Group при VU Amsterdam, и Scuola Superiore Sant'Anna описали вариант атаки под названием Branch Target Reuse, или BTR. Проблеме присвоили идентификаторы CVE-2026-64507 и CVE-2026-64508, а исправления уже попали в Linux kernel.
Суть атаки завязана на предсказателе ветвлений процессора. В Spectre v2 CPU можно подтолкнуть к кратковременному выполнению инструкций по ошибочно предсказанному адресу, а следы этого выполнения затем считываются через кэш. BTR использует похожий принцип, но бьёт в неприятный зазор между JIT-компиляцией, повторным использованием памяти под код и состоянием branch predictor. Если JIT-движок освобождает участок с машинным кодом и размещает по тому же адресу новый код, процессор всё ещё может помнить старую цель косвенного перехода.
В нормальном исполнении программа пошла бы по одному пути, но при спекулятивном выполнении CPU на короткое время может прыгнуть к устаревшей цели. Этого окна достаточно, чтобы выполнить подготовленные атакующим инструкции, задеть защищённые данные и оставить измеримый след в кэше. Дальше начинается терпеливая, байт за байтом, реконструкция секрета.
Самый неприятный результат исследователи показали на Linux cBPF. Они использовали непривилегированные classic BPF-программы, чтобы обучить предсказатель, освободить исходную программу и разместить другую в переиспользованной памяти. Затем нашли работающий процесс su и считали из его памяти хеш root-пароля со скоростью около 8 байт в секунду. На ядрах Intel Raptor Cove парольный хеш утекал в среднем за 3 минуты, на Lion Cove — за 5 минут.
Важно не путать хеш с паролем в открытом виде. Получив хеш, атакующий ещё должен его взломать: успех зависит от алгоритма, соли, политики паролей и вычислительных ресурсов. Но для защитника это слабое утешение. Если хеш root-пароля можно стабильно вынести из памяти за несколько минут из непривилегированного контекста, модель угроз для многопользовательских Linux-систем, CI-хостов, shared-инфраструктуры и рабочих станций разработчиков становится заметно менее уютной.
Исследователи проверили не только стандартную конфигурацию Linux cBPF. Они также показали вариант эксплуатации при включённой защите constant blinding: атака адаптируется и кодирует управляемые инструкции через смещения переходов, всё равно укладываясь примерно в пять минут. Это важная деталь: речь не о лабораторном трюке, который ломается от первого же hardening-флага.
Firefox SpiderMonkey и Oracle GraalVM тоже попали в поле зрения. Для SpiderMonkey команда показала, что устаревшие предсказания переживают повторное использование кода, но полноценный браузерный эксплойт не собрала. В GraalVM исследователи нашли путь к спекулятивному обходу sandbox-проверки, однако активность самого движка очищала предсказания быстрее, чем удавалось завершить атаку. Иными словами, браузеры и JIT-платформы не получили готовый универсальный эксплойт, но получили ещё одно доказательство: граница между «теоретически интересно» и «практически больно» в side-channel атаках продолжает двигаться.
Контекст здесь тянется с 2018 года, когда Spectre и Meltdown превратили микроархитектуру процессоров из темы для узких специалистов в регулярную головную боль инфраструктурных команд. С тех пор появились RIDL, BHI, SLAM и другие работы VUsec по спекулятивному выполнению. BTR неприятна тем, что бьёт по предположению, на котором индустрия держалась несколько лет: self-modifying code и динамическая генерация кода в обычных JIT-движках считались плохой почвой для практичных атак такого типа. Новая работа показывает, что почва вполне плодородная.
По оценке VUsec, проблема шире одной линейки Intel. Исследователи утверждают, что подтвердили поведение на протестированных CPU Intel, AMD и Arm, потому что косвенное предсказание ветвлений встроено в современную архитектуру процессоров. При этом продемонстрированный end-to-end сценарий с утечкой root-хеша описан именно для Linux на Intel. Это важная оговорка: «уязвим механизм» не всегда означает «готов эксплойт одинаково работает везде».
Практический список действий для команд короткий и без романтики: обновить ядро Linux до версии с исправлениями, поставить доступные обновления ОС и firmware, проверить политику непривилегированного BPF там, где она актуальна, и пересмотреть использование общих хостов для задач с разным уровнем доверия. Для разработчиков JIT-движков и runtime-платформ вывод сложнее: переиспользование памяти под код теперь надо рассматривать не только как вопрос производительности, но и как часть поверхности атаки.
Главный вопрос после атаки BTR уже не в том, появится ли ещё один вариант Spectre v2, а в том, как долго индустрия будет чинить каждый новый побочный канал патчами вокруг старой архитектурной идеи. Подробности исходного разбора доступны у ; для инфраструктурных команд ближайший вывод проще: обновления CPU-класса больше нельзя откладывать в папку «посмотрим после релиза».