Уязвимость, позволяющая обойти механизм защиты Intel TDX, вскрыта в ходе совместного аудита безопасности, проведённого специалистами Google и Intel. Проверка касалась версии Intel TDX 1.5 (Trusted Domain Extensions) — технологии, которая шифрует память виртуальных машин и должна защищать их от вмешательства администратора хоста, операторов инфраструктуры и даже от ряда физических атак на оборудование. По итогам анализа было обнаружено 6 уязвимостей и ещё 35 ошибок, формально не влияющих на модель безопасности, но указывающих на качество реализации.
Проблемы затрагивают процессоры Intel Xeon 6, а также четвертое и пятое поколения линейки Intel Xeon Scalable. Для устранения найденных уязвимостей уже выпущено обновление микрокода, распространяемое производителем. Параллельно опубликован набор инструментов для тестирования и эксплуатации проблем в Intel TDX, включая прототипы эксплоитов для двух конкретных уязвимостей — CVE-2025-30513 и CVE-2025-32007.
Ключевая, наиболее критичная из найденных проблем — уязвимость CVE-2025-30513. Она позволяет администратору хост-системы, которому по модели доверия нельзя полностью верить, повысить свои привилегии в контексте защищённой среды и фактически свести на нет гарантии безопасности, декларируемые Intel TDX. Иными словами, механизм, который должен защищать гостевую систему даже от привилегированного хост-админа, может быть обойден.
Суть уязвимости связана с состоянием гонки в одном из модулей TDX, которое проявляется во время миграции виртуальной машины. В этот момент злоумышленник с правами администратора хоста может перевести доверенную доменную среду (TD — Trusted Domain) из режима, предназначенного для миграции, в состояние, допускающее перевод в отладочный режим. Это уже само по себе противоречит ожиданиям от системы, которая заявлена как средство жёсткой изоляции гостя от хоста.
Причина проблемы — возможность подмены атрибутов защищённого окружения в небольшом временном окне: уже после проверки этих атрибутов, но до того, как они будут зафиксированы и помечены как неизменяемые в мигрировавшем окружении. Если в этот момент навязать окружению отладочный атрибут, то TDX будет считать, что запуск в отладочном режиме допустим и легитимен.
После успешной подмены параметров администратор хост-системы получает возможность подключиться к защищённой гостевой системе как к отлаживаемому объекту: отслеживать выполнение кода в реальном времени, анализировать содержимое регистров и, главное, видеть содержимое памяти уже в расшифрованном виде. Однако изначальная цель TDX как раз заключалась в том, чтобы исключить подобный доступ даже при полном контроле над гипервизором.
Эксплуатация уязвимости не требует нестандартных условий. Администратор хоста может в любой момент инициировать live-миграцию защищённой виртуальной машины, после чего воспользоваться описанным окном возможностей. Обнаружили проблему исследователи из Google, детально изучавшие API TDX и внутреннюю логику конечного автомата (FSM), который отслеживает и описывает переходы состояний защищённой среды.
В ходе анализа они заметили несоответствие: состояние операции импорта и обработка её прерывания в FSM меняются, но при возникновении сбоя состояние окружения не полностью возвращается к исходному. Это и создало ситуацию, в которой можно вмешаться в переход состояний и навязать нужные атрибуты доверенному домену в неподходящий момент.
Помимо критической CVE-2025-30513, выявлен ряд менее опасных, но всё же значимых уязвимостей. Некоторые из них традиционны для низкоуровневого системного кода: целочисленные переполнения, выходы за пределы буфера, использование неинициализированных переменных, ошибки обработки редких или «невозможных» состояний. Часть из найденных проблем по классификации исследователей не даёт прямой возможности нарушить модель безопасности TDX, но показывает, что комплексная формальная валидация и строгие практики безопасного программирования применялись не в полной мере.
Особый интерес вызывает обсуждение причины появления таких ошибок в коде столь критичной подсистемы. Многие проблемы упираются в особенности и недостатки традиционных системных языков вроде C и C++, где целый класс опасных конструкций по умолчанию не запрещён, а ошибки вроде использования неинициализированных переменных трактуются как поведение «без определения» (undefined behavior). Для компилятора это означает, что он вправе оптимизировать подобный код как угодно, исходя из предположения, что до такого состояния программа никогда не дойдёт.
С точки зрения безопасности это крайне неудобная ситуация. Разработчик может быть уверен, что его программа «логически корректна», однако агрессивные оптимизации, основанные на допущении о невозможности неопределённого поведения, нередко приводят к появлению трудноуловимых уязвимостей. В системном коде, отвечающем за защиту изолированных окружений и шифрование памяти, подобные ошибки особенно чувствительны.
При этом часть проблем могла бы быть выявлена ещё на этапе разработки при более жёстком использовании опций компиляторов, статического анализа и санитайзеров. Запрет неинициализированных переменных, строгий контроль границ массивов, обязательное покрытие критических путей тестами с инструментированием — всё это давно является обязательным минимумом в безопасной разработке, но на практике нередко применяется неравномерно.
Для пользователей и заказчиков, делающих ставку на аппаратную изоляцию, выявление таких уязвимостей — серьёзный сигнал. Intel TDX позиционировался как ответ на недоверие к администраторам облаков и операторам инфраструктуры: идея в том, чтобы даже владелец физического сервера с полными правами не мог просматривать содержимое памяти гостевой виртуальной машины и извлекать из неё ключи, данные пользователей или коммерческие секреты. Уязвимость, позволяющая обойти этот барьер, фактически разрушает основную ценность технологии — пусть и временно, до выхода исправлений.
Важно понимать, что эксплуатация описанной уязвимости доступна тем, кто уже обладает значительными привилегиями: без прав администратора хост-системы инициировать миграцию и манипулировать окружением TDX нельзя. Это не удалённая «дыра» для случайного внешнего злоумышленника, а инструмент для атак изнутри инфраструктуры — со стороны операторов, недобросовестных сотрудников или взломанных учётных записей админов.
Технология Intel TDX уже несколько лет интегрируется в экосистему: поддержка появилась в Linux ещё в 2022 году, крупные облачные провайдеры начали тестировать и рекламировать конфиденциальные виртуальные машины, основанные на этой технологии. На этом фоне каждая серьёзная уязвимость в доверенной среде получает широкий резонанс, поскольку напрямую бьёт по доверию к идее аппаратного «конфиденциального облака».
Вместе с тем сам факт проведения совместного аудита и оперативного выпуска микрокодных обновлений показывает, что технология находится в активной фазе доработки. Подобные аудиты, особенно независимые и с участием сторонних исследователей, — единственный практический путь к тому, чтобы уменьшать число критичных ошибок в столь сложных подсистемах. TDX сочетает в себе микрокод, прошивки, драйверы, гипервизор, ядро ОС и пользовательские компоненты, и без многослойной проверки здесь не обойтись.
Отдельный пласт вопросов касается физической безопасности. Хотя TDX и призван усложнять извлечение данных с физического сервера (например, с использованием атак по шине памяти или прямому доступу к DRAM), никакая логическая изоляция не спасает от уязвимостей, допускающих перевод среды в отладочный режим или обход механизмов шифрования. В этом смысле найденная уязвимость демонстрирует: если удаётся заставить систему считать отладку «легитимной», то даже хорошо продуманная криптография не поможет.
Для практического применения Intel TDX в корпоративных и облачных сценариях из всего произошедшего можно сделать несколько выводов. Во‑первых, доверие к аппаратным средствам защиты всегда должно быть условным и сопровождаться процедурами обновления микрокода и прошивок по мере выхода исправлений. Во‑вторых, модель угроз обязана учитывать риск злоупотребления правами администраторов инфраструктуры: наличие TDX или аналогичных технологий не отменяет необходимости организационного контроля, аудита действий админов и сегментации полномочий.
В‑третьих, разработчики систем, зависящих от TDX (гипервизоры, платформы управления виртуальными машинами, контейнерные решения), должны быть готовы к тому, что интерфейсы и контракт безопасности доверенной среды будут уточняться и ужесточаться. Любые предположения о «абсолютной изоляции» стоит рассматривать как временные и подлежащие постоянной верификации.
Наконец, история с уязвимостью CVE-2025-30513 ещё раз подчёркивает, что настоящая безопасность — это не только криптография и аппаратные расширения, но и качество реализации: отсутствие гонок, проверка состояний в конечных автоматах, аккуратная работа с памятью и использование современных инструментов анализа. Пока все эти элементы не работают совместно, любой, даже очень продвинутый защитный механизм, остаётся уязвимым для хорошо подготовленного атакующего.
