Сокращение поверхности атак встроенного ПО (FASR)

В октябре 2019 г. корпорация Майкрософт тесно сотрудничала с нашими изготовителями оборудования и силиконовыми партнерами для запуска компьютеров Secured-Core. Эти устройства обеспечивают глубокую интеграцию оборудования, встроенного ПО и программного обеспечения, чтобы обеспечить повышенную безопасность устройств, удостоверений и данных. Одним из основных принципов безопасности компьютеров Secured-core является обеспечение защиты встроенного ПО для устройств. Базовая аппаратно-основанная функция, необходимая для удовлетворения этого компонента, является динамическим корнем доверия для измерения (D-RTM). Однако существует не много устройств, которые предлагают D-RTM сегодня из-за зависимости от базового набора микросхем для поддержки этой возможности, что препятствует нашей приверженности повышению и поддержанию высокого уровня безопасности для всех устройств Windows.

Дополнительные возможности можно сделать для повышения уровня безопасности всех устройств Windows, включая их без D-RTM. Корпорация Майкрософт работает с партнерами по устранению проблем совместимости, которые не позволяют применять защиту памяти в встроенном ПО UEFI путем разработки набора улучшений безопасности с открытым кодом ДЛЯ обеспечения дополнительной гибкости для использования изготовителей оборудования.

Чтобы отразить эту приверженность безопасности встроенного ПО, мы определили новый подход, чтобы гарантировать, что устройства могут соответствовать требованиям защиты встроенного ПО компьютеров Secured-core.

Обзор FASR

Для компьютеров с защищенными ядрами, которые не имеют аппаратных возможностей D-RTM, необходимо определить небольшой набор компонентов встроенного ПО, которые представляют уменьшенную область атаки и могут быть подтверждены в операционной системе. Этот подход называется сокращением поверхности атак встроенного ПО (FASR). Чтобы встроенное ПО на основе FASR масштабировалось на разных компьютерах от разных поставщиков, необходимо определить новый подход к процессу загрузки встроенного ПО.

FASR поддерживает два пути загрузки:

1. Сертифицированный путь загрузки:

   • Разрешено выполнять только доверенный, подписанный и интегрированный корпорацией Майкрософт код.

   • Изменение пути загрузки определяется операционной системой.

   На рисунке ниже показан поток загрузки FASR S-RTM на сертифицированном пути загрузки. Этот путь загрузки помогает предотвратить выполнение непредвиденного кода встроенного ПО платформы. Однако он использует некоторые данные для конкретной платформы, предоставляемые пользовательским путем загрузки. На следующей схеме показан поток загрузки FASR на сертифицированном пути загрузки.

   

2. Пользовательский путь загрузки: все код встроенного ПО платформы может выполняться. Критически важные сведения, относящиеся к определенному изготовителю оборудования или платформе, преобразуются в данные по пользовательскому пути загрузки и используются сертифицированным путем загрузки для правильной настройки системы на этом пути загрузки. На следующей схеме показан поток загрузки FASR на пользовательском пути загрузки.

   

   Устройство FASR с поддержкой соответствия защищенным компьютерам по умолчанию использует сертифицированный путь загрузки, если событие не произошло, что приведет к переключении загрузки на пользовательский путь загрузки в начале процесса загрузки встроенного ПО. Примеры таких событий включают обновление встроенного ПО, запрос пользователя пользовательского интерфейса встроенного ПО или отключение защищенного ядра КОМПЬЮТЕРА, что означает, что они всегда будут загружаться на пользовательском пути загрузки до тех пор, пока он не будет повторно загружен.

   Пользовательская загрузка может использоваться для загрузки любой операционной системы или стороннего программного обеспечения, поддерживаемых встроенного ПО платформы на устройстве с поддержкой FASR, но Windows не распознает загрузку на пользовательском пути загрузки как совместимый с Защищенным ядром пк.

Чтобы лучше понять технологии безопасности, лежащие в основе FASR, мы хотели бы поделиться кратким обзором процесса загрузки Windows.

Процесс загрузки Windows

Корневой каталог доверия

Начальное выполнение встроенного ПО на современном компьютере следует загрузочным процессом, когда начальный набор кода загружает другой код, а уровень функциональности расширяется по мере выполнения загрузки. Каждый набор кода проверяет следующий набор кода, формируя цепочку доверия. Когда встроенное ПО UEFI получает контроль, он следует стандарту безопасной загрузки проверки подписей программного обеспечения, чтобы продолжить цепочку доверия вплоть до операционной системы. Затем загрузчик Windows продолжает цепочку доверия с доверенной загрузкой, которая проверяет все остальные компоненты ОС в процессе запуска перед загрузкой.

Как правило, злоумышленники стремятся получить контроль как можно раньше в процессе загрузки до включения функций безопасности и блокировок, которые помогают защитить систему. При выходе системы из сброса начальный набор кода, выполняемый в доверии, должен быть привязан к доверию. Технология проверки оборудования, которая выполняет роль для выполнения этой ранней проверки кода, называется корнем доверия. Хотя точные сведения зависят от поставщика оборудования, все корни доверия обычно коренятся в неизменяемом оборудовании или roMs в SOC.

Измеряемая загрузка

Безопасная загрузка, привязанная к корню доверия, помогает убедиться, что цифровая подпись всех встроенного ПО проверяется; тем не менее, также желательно иметь запись о том, что именно выполняло встроенное ПО. Программа совместимости оборудования Windows требует, чтобы все компьютеры Windows 10 и Windows 11 включали микросхему, называемую доверенным платформенным модулем (TPM). TPM содержит расположения памяти с именем "Регистры конфигурации платформы" (PCR). Каждый PCR содержит хэш для типа кода и (или) данных, загруженных во время загрузки, таких как код встроенного ПО на ненулевом устройстве хранилища (например, вспышка SPI), параметр ROMS с устройств PCI или загрузчик ОС. Размер значения, которое может храниться в PCR, определяется размером хэша поддерживаемого алгоритма хэширования. Например, PCR SHA-1 может хранить 20 байт, а PCR SHA-2 может хранить 32 байта. Несколько PCR, связанных с тем же алгоритмом хэширования, называются банком. Спецификация профиля TPM клиента TPM клиента TCG определяет включение по крайней мере одного банка PCR с 24 регистрами.

При наличии доверенного платформенного модуля каждый компонент встроенного ПО также может обновить или расширить соответствующий PCR, так как новый код и данные загружаются в процессе загрузки. Процесс расширения обновляет значение PCR в качестве выходных данных из хэш-алгоритма, используя текущее значение PCR, сцепленное с новым кодом или аргументом данных в качестве входных данных. Результатом является то, что pcR можно проверить после процесса загрузки, чтобы определить, что выполнено. Это позволяет программному обеспечению в операционной системе понять, отличается ли процесс загрузки от предыдущей загрузки. В конфиденциальной среде безопасности операционная система может быть проинформирована о точном наборе измерений кода, ожидаемых в определенных PCR, чтобы обнаружить выполнение неожиданного кода встроенного ПО. Так как первые 16 PCR в банке могут быть сброшены только путем сброса всего доверенного платформенного модуля и предпочтительного расположения для хранения важных измерений в доверенном платформенный модуль.

Корень доверия для измерения

Теперь, когда мы изучили роль корня доверия и как используется измеряемая загрузка, мы рассмотрим два распространенных подхода к созданию корня доверия для создания цепочки измерений в TPM: статический и динамический.

Статический корень доверия для измерения (S-RTM) устанавливает доверие при сбросе системы и требует, чтобы доверие сохранялось в течение всего процесса загрузки. Если доверие скомпрометировано в любой момент в процессе загрузки, это неизменяемо до сброса системы. На следующей схеме показано, как S-RTM используется в сертифицированном пути загрузки.

В отличие от этого динамический корневой каталог доверия для измерения (D-RTM) доверяет небольшой части кода встроенного ПО инициализации раннего набора микросхем и агент оборудования, который используется для динамического установления доверия во время загрузки. Система может первоначально загрузиться в ненадежный код встроенного ПО, но вскоре после запуска возвращается к доверенному состоянию, принимая контроль над всеми ЦП и заставляя их вниз известный и измеряемый путь. На следующей схеме представлен обзор традиционного потока D-RTM.

Существует компромисс между S-RTM и D-RTM. S-RTM не требует специальных аппаратных возможностей, но требует программного обеспечения для лучшей учетной записи кода, выполняемого во время всей загрузки. D-RTM требует специальных аппаратных возможностей, но позволяет программному обеспечению динамически запускаться в надежное состояние во время существования системы.

Компьютеры с защищенными ядрами Windows использовали D-RTM в Безопасном запуске, чтобы обеспечить гибкость для широкого набора системных производителей для реализации уникальных функций и возможностей встроенного ПО, а также помогают гарантировать, что система может достичь надежного и измеряемого состояния, приемлемого для размещения безопасной операционной среды. Событие запуска D-RTM используется для восстановления доверия из неизвестной среды перед загрузкой безопасного ядра. На следующей схеме показано событие запуска D-RTM для повторного создания известной системной среды.

В прошлом S-RTM можно реализовать на более устройствах из-за отсутствия зависимости от специальных аппаратных возможностей для проверки состояния безопасности системы, но операционная система не имеет надежного метода, чтобы подтвердить, что оно может доверять измерениям, сообщаемых на любом устройстве Windows с помощью S-RTM.

Улучшения безопасности встроенного ПО

Свести к минимуму компоненты встроенного ПО в пути загрузки ОС

Одним из способов доверия к измерениям S-RTM является сокращение компонентов встроенного ПО, разрешенных для выполнения до минимального набора. Если все устройства, использующие S-RTM, использовали один и тот же набор компонентов встроенного ПО, операционная система должна доверять только одному набору ожидаемых значений PCR для тех известных и доверенных компонентов. Благодаря этому подходу на основе SRTM устройство может быть удовлетворено требованием защиты встроенного ПО для компьютеров Secured-core, если набор загрузочного встроенного ПО проверяется только на программное обеспечение, подписанное корпорацией Майкрософт, которое может быть проверено Windows. Чтобы лучше понять, как эти компоненты встроенного ПО отличаются от этих компонентов в обычной загрузке компьютера, давайте рассмотрим процесс загрузки до и после.

Благодаря гибкости и богатому набору функций, предлагаемых современным встроенном ПО пк, код, который выполняется до операционной системы, приводит к увеличению области атак. На следующей схеме показан пример традиционного потока загрузки S-RTM.

Основные обязанности встроенного ПО во время загрузки могут быть значительно упрощены:

• Для конкретной платформы: функциональные возможности, которые применяются только к определенной архитектуре оборудования платформы.

• Неплатформенные функции: функциональные возможности, стандартные и распространенные для других оборудования.

Относительно небольшое подмножество современного встроенного ПО обычно зависит от платформы. Большая часть кода инфраструктуры встроенного ПО, выполняющего распространенные задачи, такие как выделение памяти, отправка драйверов встроенного ПО, обработка событий и т. д., совпадает между всеми (или большинством) систем на основе UEFI. Двоичные драйверы встроенного ПО для этих задач можно повторно использовать на компьютерах. Кроме того, стандартные отраслевые спецификации оборудования и интерфейсы позволяют общим драйверам встроенного ПО инициализировать жесткие диски, USB-контроллеры и другие периферийные устройства. Двоичные драйверы встроенного ПО для этого оборудования также можно повторно использовать на компьютерах. В целом компьютеры можно загрузить с минимальным набором распространенных драйверов встроенного ПО.

Сокращение общего набора драйверов встроенного ПО, загруженных во время загрузки, может привести к другим преимуществам:

• Улучшено время загрузки

• Уменьшение координации поставщиков для обновлений

• Уменьшение уязвимости ошибок

• Снижение уровня атак

Проверка пути загрузки FASR и соответствие защищенным ядрам

Чтобы система FASR соответствовала требованиям защиты встроенного ПО компьютеров Secured-core, она должна быть загружена на сертифицированный путь загрузки. Встроенное ПО FASR упрощает это путем предоставления операционной системы подписанного Корпорацией Майкрософт манифеста FASR (измеряемого в TPM), который содержит ожидаемые значения PCR для последовательности загрузки модуля в сертифицированном пути. Это можно сравнить с фактической последовательностью загрузки, которая произошла на сертифицированном пути. Если эти измерения соответствуют, система считается, что выполнила требование защиты встроенного ПО программы защищенного ядра. Любое отклонение от ожидаемой последовательности сертифицированных загрузочных путей приводит к непредвиденным измерениям, сделанным в регистрах конфигурации платформы (PCR) доверенного платформенного модуля, который обнаруживает операционная система.

Кроме того, Windows будет выпускать только защищенные гипервизором секреты при успешной проверке подписанного манифеста FASR по измерениям, записанным во время текущей загрузки. Если в сертифицированном загрузочном пути или обновлении капсулы манифест FASR отсутствует, проверка подписи завершается ошибкой или происходит несоответствие PCR, и секреты VSM не будут неуправляемы или перенесены.

Как встроенное ПО FASR устраняет защиту памяти и СММ

Теперь, когда был определен один двоичный файл, подписанный корпорацией Майкрософт с минимальным набором функциональных возможностей, он может включать основные, но отсутствующие средства защиты встроенного ПО Майкрософт работают с партнерами для привлечения на рынок. Сертифицированный путь загрузки должен соответствовать минимальным требованиям:

1. Код не считывает и не записывает данные в NULL/Page 0

2. Фрагменты кода изображения и данных разделены

3. Разделы изображения выровнены по границе страницы (4 КБ)

4. Данные выделяются только в типы памяти данных и код в типы памяти кода

5. Образы кода не загружаются из кода, распределенного как двоичные файлы UEFI (только назначенные диспетчеры)

6. Код остается в пределах выделенных буферов памяти с защищенными страницами вокруг выделения страниц

7. Можно обнаружить переполнение стека

8. Код не выполняется из стека

9. Для включения защиты NXX задана характеристика DLL /NXCOMPAT.

Сторонние параметры РОМ, приложения UEFI и драйверы UEFI часто не были созданы или проверены в соответствии с этим набором требований. Таким образом, они не будут выполняться на сертифицированном пути загрузки. Пользовательский путь загрузки может при необходимости снизить уровень защиты, но этот путь загрузки не считается защищенным компьютером, соответствующим операционной системе.

Режим управления системой (СММ)

СММ — это специальный режим работы процессора в архитектуре x86. Она представляет собой уникальную проблему для обеспечения безопасности системы, так как код, выполняемый в среде SMM, непрозрачн для операционной системы и обычно выполняется на самом высоком уровне привилегий (иногда называется "Ring -2") любого программного обеспечения на хост-процессоре. При входе КОМАНДА СММ настраивает собственную среду, настраивая таблицу страницы, таблицу отправки прерываний (IDT) и другие системные структуры. НАБЛЮДАТЕЛЬ представляет значительную область атаки, которая может использоваться вредоносным кодом для компрометации или обхода защиты ОС, включенной с помощью безопасности на основе Виртуализации (VBS). Чтобы помочь устранить опасность, связанную с СММ, функциональные возможности в СММ могут быть концептуально разделены на основную инфраструктуру СММ и драйверы СММ следующим образом:

• Ядро СММ: код, который является общим для всех реализаций СММ, выполняющих архитектурные и инфраструктурные обязанности

• Драйверы СММ: код, написанный для выполнения задачи конкретной платформы в МИССИЯХ

Ниже приведены некоторые ключевые моменты жизненного цикла СММ.

1. При создании фонда СММ (или ядра) — начальная загрузка программы (IPL) СММ

2. Когда драйверы СММ загружаются , называется диспетчером ДРАЙВЕРОВ ДЛЯ СММ

3. При входе в СММ — через прерывание управления системой (SMI)

Начальная загрузка программы СММ (IPL)

ЦП имеет специальные функции, которые предоставляют код ДЛЯ СММ высокой привилегии и помогают защитить его. Например, механизм определяется для ввода СММ с помощью программных или аппаратных событий, инструкция ЦП используется для возврата из СММ, а для управления доступом и блокировкой конфигурации СММ определяется несколько регистров. Многие из этих регистров управления настраиваются кодом IPPL ДЛЯ ограничения доступа к области памяти, в которой хранятся код и данные СИСТЕМЫ (называется ОЗУ управления системой или SMRAM).

Так как область SMRAM находится в основной памяти (DRAM), ее нельзя установить, пока во время загрузки не будет включенА DRAM. Процедуры включения DRAM зависят от поставщика кремния, но довольно несколько мегабайт кода могут выполняться непосредственно из кэша ЦП LLC (включая код, который инициализирует DRAM), прежде чем основная память доступна.

Встроенное ПО FASR приносит точку IPPL ранее в загрузке, чем большинство других систем. Это сокращает возможность, когда злоумышленник должен подорвать этот процесс и взять под контроль систему перед настройкой СММ. Чтобы лучше понять это и другие усовершенствования, внесенные в ПРОГРАММАХ УПРАВЛЕНИЯ встроенного ПО FASR, необходимо узнать больше о процессе загрузки встроенного ПО.

Загрузка инициализаций платформы (PI) в встроенном ПО UEFI

Современное встроенное ПО пк построено на основе многих спецификаций. Спецификация UEFI определяет интерфейс между совместимой с UEFI операционной системой, например Windows, и встроенного ПО на устройстве. Другая спецификация, называемая спецификацией инициализации платформы (PI), определяет способ создания драйверов встроенного ПО и подробных сведений о процессе загрузки. На высоком уровне спецификация UEFI может рассматриваться как одна из стандартизаций, которая позволяет одному образу Windows работать с таким количеством различных устройств, и спецификация PI может рассматриваться как одна из стандартизаций, которая позволяет так много образов встроенного ПО от разных поставщиков оборудования работать вместе. Обе спецификации поддерживаются форумом UEFI.

Спецификация pi определяет этапы загрузки и которые драйверы записываются на этапы загрузки. Во время загрузки встроенного ПО каждый этап переходит к следующему, и в большинстве случаев драйверы из этапа передачи больше не используются, и только важные данные передаются на следующий этап, чтобы он смог продолжить процесс загрузки. Этапы загрузки можно суммировать следующим образом:

1. SEC — получение управления в векторе сброса ЦП и переход с сборки на код C для загрузки PEI

2. PEI — инициализация состояния системы для загрузки DXE и инициализации DRAM

3. DXE — выполнение оставшейся инициализации системы, которая включает предоставление поддержки BDS, необходимой для загрузки операционной системы.

4. BDS — обнаружение параметра загрузки для текущей загрузки (например, загрузчика ОС) и попытка загрузки этого параметра

5. ОС — ядро операционной системы

Защита начальной загрузки программы (IPL) СММ

Традиционное встроенное ПО UEFI PI, соответствующее спецификации UEFI, загружает IP-интерфейс IPPL на этапе загрузки DXE. Встроенное ПО FASR загружает IP-интерфейс IPPL на этапе загрузки PEI. База доверенных вычислений (TCB) для системы — это общий набор механизмов защиты, которые защищают его, включая оборудование, встроенное ПО и программное обеспечение. При перемещении IP-адреса ИЗ DXE в PEI весь этап DXE (который является более крупной и богатой средой, чем PEI), удаляется из TCB. На следующей схеме показана функция IPPL, перенесенная ранее в процессе загрузки UEFI.

Код PEI и DXE выполняются в кольце 0 и не сохраняются (с небольшими исключениями) в операционной системе. Код СММ выполняется с более высоким уровнем привилегий, чем кольцо 0 (и гипервизор) и сохраняется в операционной системе, поэтому не позволяя уязвимости DXE влиять на создание СММ снижает общую область атаки системы. Кроме того, поскольку ранее в процессе загрузки запущена СИСТЕМА БЕЗОПАСНОСТИ, биты блокировки, заданные для защиты СММ, можно включить ранее в загрузке, что еще больше сводит к минимуму окно злоумышленника для компрометации СММ.

Защита процесса отправки драйвера СММ

В спецификации PI определены два режима СММ: традиционный ММ и автономный ММ. Традиционная MM эквивалентна модели программного обеспечения ДЛЯ СМЭ, которая исторически используется в встроенном ПО, совместимом с PI, которая представляет собой большинство встроенного ПО UEFI в отрасли. Автономный ММ является относительно новым режимом, который пересматривает историческую модель, чтобы повысить безопасность среды СММ и предотвратить распространенные ошибки, сделанные в традиционных реализациях MM, которые привели к многочисленным проблемам переносимости и безопасности в течение многих лет.

Встроенное ПО FASR работает исключительно в автономном режиме MM. Это позволяет встроенному ПО FASR следовать дисциплинированному подходу к выполнению программного обеспечения в МИССИЯХ. Так много уязвимостей на основе СММ сегодня обусловлены плохими практиками, разрешенными в коде СММ в традиционном ММ, что может быть просто удалено в автономном ММ. На высоком уровне это происходит из-за того, что в традиционной модели ММ драйвер СММ отправляется дважды, один раз диспетчером DXE в кольцевом 0, и снова диспетчерОМ СММ в СММ. Это дает достаточно возможностей для кода драйвера, выполняемого в среде DXE, кэшировать указатели на ресурсы за пределами SMRAM, к которым они не должны получать доступ после возврата точки входа. Атаки, зависящие от кода СММ для вызова кода за пределами СММ, часто называются "атаками выноски СММ".

Защита входа в НАБЛЮДАТЕЛЬ

Данные передаются обработчику SMI через структуру, называемую буфером обмена данными. Обработчик SMI отвечает за проверку соответствия данных определенным требованиям в точке входа. Таблица устранения рисков безопасности Windows (WSMT) — это один из механизмов, используемых для устранения угрозы без проверки обработчиков SMI, представляющих безопасность на основе виртуализации в операционной системе. Корпорация Майкрософт внесла код в проект TianoCore для улучшения проверки буфера обмена данными. Помимо применения этих двух методов, код FASR также реализует строгие средства защиты доступа к памяти, что позволяет коду СМЭМ получать доступ только к явно разрешенным диапазонам памяти.

Руководитель режима управления (руководитель mm)

Основной код СММ является общим и общим для минимального изменения между системами. Поверхность нападения, введенная СММ, может быть значительно сокращена путем введения разделения привилегий в среду СММ. По этой причине встроенное ПО FASR включает в себя диспетчер СММ, который выполняется в автономном MM. Это приводит к четко определенной среде СММ С минимальным уровнем привилегий, который имеет уровни привилегий, примененные при создании. Руководитель mm устанавливает ограничения на доступ к портам ввода-вывода, доступ к определенному регистру модели (MSR), доступ MMIO, доступ к ЦП сохранения состояния и разрешенные инструкции в среде СМЭМ. Политика диспетчера СММ используется для настройки точных сведений о том, какие аппаратные ресурсы следует ограничить, и эти точные сведения могут быть изменены на поколение кремния.

Политика недавно перешёл на подход запрета по умолчанию, который значительно сокращает аппаратные ресурсы, доступные для кода за пределами диспетчера СММ. Этот руководитель работает без аппаратной зависимости от каких-либо аппаратных возможностей, которые обычно не найдены на современных компьютерах.

Руководитель MM используется в FASR с открытым исходным кодом и доступен в репозитории диспетчера project Mu MM.

Соответствие системы FASR требованиям к защищенному компьютеру

В следующей таблице указаны широкие основы безопасности или цели компьютеров Secured-Core, а также то, как системы FASR загружаются на сертифицированном пути, могут достичь требований компьютеров Secured-core:

Если в системе нет расширенных возможностей безопасности для поддержки D-RTM, требования к защите встроенного ПО можно выполнить с помощью сочетания S-RTM и автономной MM с диспетчером MM, оба из которых предлагаются встроенного ПО FASR.

Итоги

Это некоторые из инвестиций, которые корпорация Майкрософт сделала для решения растущего числа атак встроенного ПО, которые распространены в отрасли сегодня. Используя код с открытым кодом для этих изменений, мы расширяем возможности наших партнеров использовать некоторые из этих преимуществ безопасности, которые, в свою очередь, помогают более широкой экосистеме и отрасли в целом.

Основной целью инициативы по защищенному компьютеру является обеспечение доступа клиентов к некоторым из самых сложных возможностей безопасности, доступных для компьютеров Windows. При некоторых из этих изменений встроенного ПО мы на шаг ближе к реализации этой цели и обновили требования к защите встроенного ПО компьютеров Secured-core, чтобы отразить это включение. Дополнительные сведения о компьютерах с защищенными ядрами см. здесь.