Содержание
Исследователи из ETH Zurich раскрыли уязвимость Fabricked, которая обходит защиту AMD SEV-SNP на серверных EPYC. Сценарий неприятный именно для облаков: злонамеренный хост получает чтение и запись памяти «конфиденциальной» виртуальной машины и даже умеет подделывать отчёты attestation.
Команда описала атаку в работе для USENIX Security 2026. По их данным, эксплойт полностью детерминированный и даёт 100% успеха. Физический доступ не нужен. Код внутри гостевой VM тоже выполнять не требуется.
Как Fabricked обходит SEV-SNP ещё на старте загрузки
SEV-SNP придумали как ответ на базовую проблему доверия в облаке: арендатор не контролирует «железо» и не может проверить, не читает ли провайдер его данные. На EPYC это решают через Confidential Virtual Machines: память шифруют, а доступ к страницам контролирует отдельный защищённый блок — PSP (Platform Security Processor).
Ключевой элемент модели — Reverse Map Table (RMP). Это таблица по страницам памяти, которая задаёт права доступа и отделяет «чужую» память CVM от гипервизора. PSP должен корректно инициализировать RMP во время загрузки, а механизм attestation опирается на то, что эта цепочка не сломана.
Fabricked бьёт именно сюда. Атакующий хост вмешивается до того, как защита успевает нормально «закрыться».
Причина в конфигурации Infinity Fabric и доверии к UEFI
Технический корень — в Infinity Fabric, внутренней межсоединительной ткани AMD, которая маршрутизирует обмен между ядрами, контроллерами памяти и устройствами. Из-за разных конфигураций платформ часть регистров Infinity Fabric настраивает прошивка платы — UEFI.
И вот важная деталь из модели угроз AMD: UEFI в облаке считают недоверенной, потому что её контролирует провайдер. Исследователи выяснили, что UEFI должна вызвать два PSP API, которые блокируют регистры конфигурации Infinity Fabric после инициализации. Злонамеренная UEFI может просто пропустить эти вызовы. Тогда слой маршрутизации памяти (Data Fabric) остаётся доступным для записи даже после активации SEV-SNP.
Дальше включается второй баг, тоньше. Запросы PSP к памяти сначала проверялись по правилам маршрутизации MMIO (обычно это про общение с устройствами), и только потом — по обычным правилам DRAM. Если настроить MMIO-маппинги так, чтобы они «затеняли» область памяти, где лежит RMP, то записи PSP при инициализации RMP тихо отбрасываются.
В итоге RMP не поднимается как надо, но SEV-SNP всё равно сообщает об успешной инициализации. Платформа «думает», что всё защищено, хотя это не так.
Что даёт атакующему: чтение памяти CVM и подделка attestation
Если RMP не инициализирован и остаётся под контролем атакующего, гипервизор получает возможность читать и менять память конфиденциальной VM. Исследователи показали два практических сценария.
- Включение debug mode: после attestation можно активировать отладочный режим на production-CVM, и гипервизор сможет незаметно расшифровывать произвольную память гостя.
- Подделка attestation: можно полностью подделывать отчёты, чтобы вредоносный образ выглядел как доверенный.
Какие платформы затронуты и что сделала AMD
Исследователи подтвердили атаку на AMD Zen 5 EPYC. В материалах AMD также фигурируют обновления прошивок для Zen 3 и Zen 4, что намекает на более широкую зону риска по поколениям.
AMD признала проблему после ответственного раскрытия от ETH Zurich в августе 2025, присвоила уязвимости идентификатор CVE-2025-54510 и выпустила рекомендации в бюллетене AMD-SB-3034, когда эмбарго сняли в апреле 2026.
AMD подчёркивает, что домашние ПК и обычные облачные VM, которые не используют SEV-SNP confidential computing, не затронуты. Патчи закрывают Zen 3, Zen 4 и Zen 5, а для организаций на EPYC-инстансах с SEV-SNP критично проверить у провайдера, что прошивки уже обновили.
