Об атаке на Intel TXT
Атака, представленная в этой статье, как обычно, предполагает, что злоумышленник может выполнить код до запуска TXT, т.е. до инструкции SENTER. Цель злоумышленника состоит в том, чтобы либо 1) иметь возможность скомпрометировать только что загруженный гипервизор, даже если он был только что «безопасно» загружен TXT, либо 2) иметь возможность загрузить произвольный гипервизор, но сделать так, чтобы он выглядел как доверенный, сделав все хэши PCR правильными. Так работает представленная сегодня атака. Для базового ознакомления с Intel®Trusted Execution Technology (TXT).
Наша новая атака использует ошибку в модуле SINIT. Прежде чем описывать ошибку, давайте кратко рассмотрим роль SINIT в Intel TXT.
Об аутентификационном коде (АС) модуле и SINIT
SINIT — важный двоичный модуль, используемый Intel TXT. Бинарные файлы SINIT распространяются Intel для конкретных наборов микросхем/процессоров, а задача модуля SINIT — подготовить платформу для входа в безопасный режим TXT. Модуль SINIT загружен и выполняется командой SENTER. SINIT должен иметь цифровую подпись Intel, чтобы инструкция SENTER могла загрузить и выполнить его. Таким образом, SINIT также называется Модулем Аутентифицированного Кода (Модуль AC). Существует по крайней мере еще один пример модуля AC, распространяемого Intel, SCLEAN AC Module, который может быть загружен с помощью инструкции ENTERACCS и должен использоваться BIOS с поддержкой TXT для очистки системной памяти в случае непредвиденной ошибки.
Модуль AC, такой как SINIT, при загрузке с использованием инструкций SENTER или ENTERACCS выполняется в особо защищенной и привилегированной среде. По-видимому, существуют некоторые различия между средой, предоставляемой ENTERACCS, и средой, предоставляемой инструкцией SENTER, поэтому мы сосредоточимся на последнем случае и будем называть эту специальную привилегированную среду «режимом SINIT».Одной из задач модуля SINIT является считывание и анализ конфигурации платформы в соответствии с таблицами BIOS ACPI и, в частности, таблицей ACPI DMAR, которая описывает конфигурацию платформы VT-d.
Код SINIT написан на обычной ассемблере x86, поэтому его можно дизассемблировать стандартными средствами x86 для бинарного анализа. Ниже представлен фрагмент SINIT для процессоров Sandy Bridge:
Мы видим, что приведенный выше фрагмент кода сначала считывает длину таблицы DMAR ACPI, на что указывает длина поля ненадежного заголовка ACPI DMAR, а затем пытается скопировать эту таблицу ACPI в буфер, расположенный в TXT. Таблицам ACPI нельзя доверять, потому что злоумышленник, контролирующий загрузочную среду до TXT, например, заразивший MBR системы, может свободно изменять таблицы ACPI в памяти, которые изначально были опубликованы BIOS. Таблицы ACPI не имеют цифровой подписи, поэтому невозможно обнаружить такие вредоносные модификации таблиц ACPI.
Эксплойт выполнения кода SINIT
Чтобы воспользоваться преимуществами переполнения в SINIT-коде, нам следует изменить структуру памяти и разместить код TXT (или хотя бы некоторые его части) над SINIT-кодом, чтобы переполняющие данные могли перезаписать SINIT-код. Это кажется тривиальной задачей, потому что системное программное обеспечение (а также злоумышленник в этом случае) контролирует базовый адрес кучи TXT через регистр TXT.HEAP.BASE.К сожалению, оказалось, что если попытаться поменять местами расположение кучи и SINIT, то SENTER вернет ошибку. Это может указывать на то, что Intel предвидела потенциальные ошибки в коде SINIT и хотела предотвратить перезапись кода SINIT в таких случаях. Однако есть другой способ перемещения перед кодом SINIT. Оказалось, что этого можно добиться, изменив размер первого фрагмента TXT и быть фактически отрицательным, как показано на рисунке.
Код SINIT, который считывает и копирует таблицу DMAR, помещает ее в фрагмент TXT, называемый SinitMleData. Здесь начнется переполнение. Теперь, предоставив достаточно большую таблицу DMAR, злоумышленник может переполнить код SINIT.Чтобы использовать переполнение для выполнения произвольного кода, мы нашли функцию, расположенную перед rep movsb инструкции, но которая вызывается потом. Таким образом, перезаписав эту функцию кастомным шеллкодом, мы легко можем получить произвольный код, исполняемый в контексте режима SINIT.
Как оказалось, нам также нужно было сохранить некоторые важные структуры данных в начале области SINIT, такие как, например, GDT. Мы делаем это, перезаписывая эту часть исходными байтами, извлеченными из SINIT. Это возможно, потому что мы контролируем всю таблицу DMAR, используемую для перезаписи (за исключением некоторых ранних заголовков, которые должны соответствовать спецификации DMAR). На рисунке представлен весь процесс эксплуатации:
Описанный выше процесс эксплуатации надежен, поскольку все смещения детерминированы и зависят только от актуальной версии модуля SINIT, используемого для эксплуатации. Злоумышленник всегда может загрузить и проанализировать конкретную версию SINIT перед атакой. Как мы видим, фактический процесс эксплуатации был довольно простым, и единственной нестандартной задачей было сложное перемещение макета кода.
Последствия эксплуатации SINIT: обход TXT
Одним очевидным последствием эксплойта выполнения кода SINIT является немедленная возможность прямого обхода доверенной загрузки на основе TXT. Это связано с тем, что код SINIT выполняется до большинства динамически-расширенных регистров PCR, но после того, как они были сброшены в 0 микрокодом SENTER. Расширение других PCR, в частности PCR18, который обычно расширяется хэшем загружаемого MLE, остается задачей SINIT.
Поскольку модуль SINIT, который мы используем в этой атаке, является полностью законным, распространяемым Intel, оригинальным SINIT, PCR17 будет расширен с помощью правильного хеша перед передачей выполнения в SINIT. Оказалось, что SINIT сначала разберет таблицу DMAR, прежде чем измерять MLE и расширять PCR18. Это означает, что во время выполнения нашего шелл-кода PCR18 и другие PCR с более высокими номерами все еще равны нулю. Это означает, что наш шелл-код теперь может свободно расширять PCR18 с помощью произвольного хэша, например хэша какого-то законного MLE, но при этом может передавать выполнение другому MLE, например вредоносному, как показано на рисунке ниже:
Схема эксплуатации последовательности SINIT: обход LCP
LCP применяется модулем SINIT, и выполняется после синтаксического анализа таблицы DMAR, то есть после того, как мы используем SINIT для выполнения нашего шелл- кода. Это означает, что мы можем просто пропустить принудительный код LCP, полностью игнорируя любую политику LCP, которую мог настроить пользователь.
Одним из практических сценариев является игнорирование потенциальной политики LCP, которая может внести в черный список сам модуль SINIT, который мы используем. Если бы такую политику LCP можно было применить, это было бы удобным решением против нашей атаки. Однако, поскольку мы можем тривиально обойти любую политику LCP, это не cработает, чтобы остановить нашу атаку.
Последствия эксплуатации SINIT: угон SMM
Еще одним интересным последствием нашей SINIT-атаки является возможность компрометации обработчика SMM платформы. Это связано с тем, что модулю SINIT обычно предоставляется разблокированный доступ к SMRAM, как указано в Intel SDM:
SignalTXTMsg(UnlockSMRAM);
SignalTXTMsg(OpenPrivate);
SignalTXTMsg(OpenLocality3);
EIP -> ACEntryPoint;
Выше приведен фрагмент псевдокода инструкции SEN-TER. Мы видим, что непосредственно перед тем, как выполнение передается модулю AC, то в этом случае наш модуль SINIT, SMRAM, личное пространство TXT и местоположение будут разблокированы. Поскольку наш шелл-код выполняется в контексте модуля SINIT, это означает, что ему также будет предоставлен доступ к SMRAM.Теоретически модуль SINIT можно было бы написать таким образом, чтобы он добровольно блокировал доступ к SMRAM в самом начале, прежде чем пытаться проанализировать таблицу DMAR (то есть до того, как наш шелл-код получит возможность выполниться), но мы убедились, что это не так. Помимо других атак, связанных с SMM (например, руткитов SMM), это позволяет провести еще одну интересную атаку...
Предположим, что после того, как мы проинформировали Intel об атаке SINIT, Intel выпустила рекомендацию, призывающую клиентов повторно запечатать свои секреты в новый хеш PCR17 для обновленного модуля SINIT. Теперь наша прямая атака в обход TXT больше не будет работать, потому что PCR17 будет содержать неправильный хеш во время выполнения нашего шеллкода. Однако теперь мы можем использовать эксплойт SINIT, чтобы получить доступ к SMRAM, установить лазейку в обработчике SMI, выйти из режима AC, а затем повторно запустить исходный MLE, используя новый, исправленный SINIT (таким образом, выполняя законный запуск ТХТ).Мы убедились, что действительно можем изменить обработчик SMI из шелл-кода эксплойта SINIT, выйти из режима SINIT (используя инструкцию EXITAC) и что наши модификации SMM выдерживают эту операцию. Поскольку скомпрометированный обработчик SMI переживает также запуск TXT, наш бэкдор в SMM теперь сможет скомпрометировать только что загруженный законным образом MLE при первом возникновении прерывания SMI (что обычно происходит сразу после того, как MLE активирует SMI).
Intel может решить эту проблему двумя способами:
1. Надлежащим способом решения этой проблемы было бы выпустить STM, т. е. специальный компонент, распространяемый как часть BIOS, который должен изолировать потенциально вредоносный код SMM.
2. Intel также может выпустить обновление микрокода, которое либо отключит разблокировку SMRAM, выполняемую как часть инструкции SENTER, и/или занесет в черный список ошибочный SINIT, который мы используем для эксплуатации. Кроме того, чтобы эта защита имела смысл, обновление микрокода должно быть применено в BIOS, чтобы злоумышленник не мог отказаться от нового микрокода (обновление микрокода должно применяться при каждой загрузке платформы, поскольку он является непостоянным), а также новое обновление микрокода должно изменить существующую процедуру обновления микрокода, чтобы не допустить понижения версии микрокода, поскольку в противном случае злоумышленник может просто вернуться к более старому микрокоду, который бы не блокировал глючный SINIT или отключал доступ к SMRAM.
Если бы Intel решила пойти по второму пути и не выпускать работающий STM на свои платформы, это также имело бы интересное последствие включения BIOS в доверенную базу TXT. Это связано с тем, что если злоумышленник смог разрушить BIOS, например, скомпрометировав механизмы защиты от перепрошивки BIOS, тогда злоумышленник сможет отказаться от обновления микрокода, которое заносит в черный список ошибочный SINIT (или отключает предоставление доступа к SMRAM как части SEN-TER), и проводит описанную выше атаку с обходом TXT.
Итог
Похоже, что Intel приложила немало усилий, чтобы никто не выполнял произвольный код в «режиме SINIT». Вся инфраструктура, используемая для проверки цифровых подписей модуля AC, кажется ненужным усложнением (не будем забывать, что этот процесс проверки является частью микрокода инструкции SEN-TER!). Это кажется ненужным, потому что для безопасных запусков TXT достаточно, чтобы SENTER измерял хэш SINIT и расширял с его помощью одного из динамических PCR, что и делает SENTER (PCR17 расширяется хэшем SINIT). Итак, зачем дополнительный, нетривиальный механизм проверки подписи?
Кто-то может возразить, что этот дополнительный механизм проверки был необходим для реализации политики Intel LCP, так как код принудительного применения политики реализован сам по себе внутри модуля SINIT. Однако следует помнить, что Intel LCP сама по себе является механизмом. На самом деле нет ничего, что могло бы заставить злоумышленника выполнить SENTER (и, следовательно, пройти политику LCP), кроме возможности заблокировать режим VMX вне режима SMX (другими словами, можно настроить платформу, обычно с помощью BIOS, чтобы запретить использование VT-x без входа в безопасный режим TXT). Тем не менее, кажется неясным, почему злоумышленник, особенно вредоносное ПО, должен так стремиться включить VT-x? В конце концов, несмотря на то, что первое вредоносное ПО для аппаратной виртуализации было представлено много лет назад, оно до сих пор не используется, потому что используемые в настоящее время операционные системы предлагают множество возможностей для гораздо более простых , традиционные атак.
