windows smm security mitigations table что это
Understanding the Windows SMM Security Mitigation Table (WSMT)
The Windows SMM Security Mitigation Table (WSMT) is an ACPI table defined by Microsoft that allows system firmware to confirm to the operating system that certain security best practices have been implemented in System Management Mode (SMM) software. The WSMT table definition is described in the Windows SMM Security Mitigations Table (WMST) specification.
Background
The WSMT was defined to better support Windows Virtualization-based Security features. Please refer to Virtualization-based Security (VBS) for more background on VBS. Because SMM operates without the operating system’s knowledge or control, SMM represents a significant attack surface that could be leveraged by malicious code to compromise or circumvent the OS protections enabled through VBS. Delivering a robust and secure VBS platform requires careful scrutiny and likely updates of SMM code by the OEM to eliminate common vulnerabilities that may be exploited. The WSMT contains flags which firmware can set to indicate to the operating system which of these specific security best practices have been implemented.
Implications of the WSMT on Windows VBS Support
The WSMT Protection Flags field indicates the presence of these specific SMM security mitigations in the systems firmware. Supported versions of the Windows operating system read the WSMT Protection Flags early during initialization, prior to hypervisor and VBS launch, and may elect to enable, disable, or de-feature certain security features based on the presence of these SMM Protections Flags.
Implementation Notes
Proper implementation of the security mitigations represented by the WSMT Protection Flags FIXED_COMM_BUFFERS and COMM_BUFFER_NESTED_PTR_PROTECTION will require the firmware vendor carefully evaluate and possibly re-design the System Management Interrupt (SMI) handlers. All SMI handlers must be restricted to only access (read or write) to allowable memory regions that contain MMIO and EFI-allocated memory. It is not sufficient to check that pointers in SMM do not reference memory entirely outside of SMM. Rather, all SMM pointers must be validated to be within these safe memory regions. This prevents SMM from being exploited in a «confused deputy» attack, which could then be leveraged to compromise Windows VBS features. The above-mentioned Protection Flags refer only to input validation and pointer checks and do NOT currently require enforcement via SMM page protections. For example, SMM should not read or write to memory that was described by the firmware as EfiConventionalMemory because it may contain secrets or cause software to behave unpredictably.
Validating the WSMT Protections
Because SMM is opaque to the operating system, it is not possible to produce a test which runs in Windows to verify that the protections prescribed in the WSMT specification are actually implemented in SMM. From the operating system, the only check that is possible is to look for the presence of the WSMT, and check the state of all defined Protection Flags.
Therefore, it is the responsibility of the OEM to carefully scrutinize each system’s SMM code and ensure that firmware complies with the guidance outlined in the WSMT specification and this article. No Protection Flag should be set to «true» until the OEM has confirmed that the mitigations corresponding to each Protection Flag value have been properly implemented. Failing to adhere to this as a best practice will leave the platform vulnerable to compromise, and negate the effectiveness of multiple OS protections and Windows security features which rely on VBS to maintain robust security boundaries.
Supported versions of Windows
Support for the WSMT is included in the following versions of Windows:
Microsoft добавит новые меры безопасности UEFI в Windows 10
В прошлых публикациях, посвященных улучшениям безопасности Windows 10 [1,2,3,4], я неоднократно хвалил Microsoft за эти полезные нововведения. Новые механизмы безопасности помогают более эффективно бороться с эксплойтами. Пока очевидно, что Microsoft все больше делает ставку на новые технологии защиты от эксплойтов, основанные на виртуализации Virtualization Based Security, при этом добавляя более современные метрики безопасности и вынося выполнение критических по безопасности операций в отдельные виртуальные машины с высоким уровнем привилегий.
На сей раз речь пойдет о безопасности прошивок UEFI. Известный гуру внутреннего устройства Windows Alex Ionescu опубликовал у себя в твиттере скриншот дополнительных требований безопасности UEFI, которые должны поддерживаться прошивками начиная с Windows 10 1703. Как известно, эта версия Windows 10 и может получить название очередного существенного обновления Redstone 2.
Не секрет, что сама прошивка, ее компоненты и драйверы в современных ПК являются почти мини-ОС, которая получает управление еще до передачи упropравления загрузчику Windows. Столь стремительное распространение UEFI подталкивает security-ресерчеров к детальному поиску уязвимостей в прошивках и их драйверах, а производителей BIOS/UEFI к пересмотру механизмов их защиты. Злоумышленнику достаточно воспользоваться уязвимостью только в одном компоненте прошивки, чтобы скомпрометировать такие продвинутые VBS- технологии защиты Windows 10 как Device Guard, Credential Guard, Windows Defender Application Guard.
Одним из подобных эксплойтов, который способен компрометировать все указанные выше технологии защиты Windows 10, основанные на виртуализации (VBS) является ThinkPwn, о котором я писал здесь. ThinkPwn использует уязвимость в драйвере прошивки для того, чтобы исполнить свой код на самом привилегированном уровне — SMM.
Рис. Абстрактные уровни привилегий исполнения кода. Высший относится к Intel ME, далее SMM и гипервизор. Компрометация UEFI-прошивки позволяет компрометировать гипервизор и основанные на нем механизмы защиты (Device Guard, Credential Guard, Windows Defender Application Guard).
Очевидно, что Microsoft учла вышеприведенные причины и добавила новые требования безопасности к прошивкам UEFI. Первое требование относится к фактической реализации DEP для прошивки. Т. е. страницы памяти с данными прошивки будут помечаться как NX (non-executable), что позволит исключить исполнение кода из ненадлежащих регионов памяти.
VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.
Вторая функция безопасности относится к защите от эксплуатации уязвимостей, связанных с системной таблицей ACPI и драйверов (сервисов) UEFI. Для этого используется новая системная структура данных под названием Windows SMM Security Mitigations Table (WSMT).
The Windows SMM Security Mitigations Table (WSMT) specification contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.
Отметим, что в обоих случаях Microsoft подчеркивает, тот факт, что введенные методы безопасности обезопасят VBS от компрометации через уязвимости в прошивке.
Reduces the attack surface to VBS from system firmware
О безопасности UEFI, часть вторая
Часть вторая. SMM
Немножечко ликбеза
Аппаратное SMI
Писать про него особенно нечего: подаем напряжение на ногу — имеем прерывание. Сейчас используется редко, т.к. почти на всех системах теперь имеются мультифункциональные GPIO, которые могут генерировать события, не прерывая работу ОС, плюс не нужна дополнительная логика для определения, кто же конкретно сгенерировал аппаратное SMI, ведь устройств много, а нога — одна.
Системные SMI
Программные SMI
Программные SMI генерируются чаще всего либо прошивкой, либо драйверами, но ничего не мешает атакующему с правами администратора в ОС (точнее, необходимы права на исполнение инструкции out) тоже генерировать их.
Программное SMI генерируется при записи в CPU IO-порт APM_CNT (чаще всего это порт 0xB2), в качестве параметра в регистре AL передается его номер. Таким образом, максимальное количество различных обработчиков программных SMI в системе — 256, но реально их от 0-5 на специализированных системах, подготовленных для работы с RTOS, до 15-20 на системах с кучей разного железа, которым надо управлять без вмешательства ОС.
Как реализован SMM
Для кода SMM-диспетчера и обработчиков SMI выделяется 1-3 области физической памяти, которую во всех «обычных» режимах исполнения чипсет помечает как область MMIO с несуществующим устройством, т.е. для всего остального мира эти области — сплошная череда 0xFF, которые невозможно перезаписать. Первая область, называемая обычно ASEG (т.е. «сегмент А»), предназначена для т.н. legacy SMM code, т.е. старых 16-битных обработчиков SMI, которых на современных системах уже нет. Имя сегменту досталось за то, что он находится по фиксированным физическим адресам 0xA0000 — 0xBFFFF. Вторая область с фиксированными адресами — HSEG (т.е. «высокий сегмент»), раньше находилась на 0xFEDA0000 — 0xFEDBFFFF, но на современных системах не используется, т.к. имеется гораздо более удобный сегмент с настраиваемыми адресом и размером — TSEG (т.е. «топовый сегмент»), в котором и находятся сейчас 99% кода, исполняемого в SMM, а в ASEG остается только небольшая заглушка для совместимости.
При переходе в SMM процессор сохраняет практически весь контекст (т.е. содержимое практически всех регистров, какие именно не сохраняются — зависит от конкретной микроархитектуры), причем к сохраненному контексту у обработчиков SMI есть полный доступ, и потому он может общаться с системой через изменение сохраненных значений.
Для ОС вызов SMM кода выглядит как волшебное изменение содержимого регистров и памяти, и хотя отследить длительность нахождения в SMM все же можно по косвенным признакам, а факт перехода в него — по непосредственным, при помощи чтения регистра MSR_SMI_COUNT до и после вызова инициации программного прерывания, но повлиять на длительность обработчика SMI ОС не может, поэтому SMM плохо совместим с hard-RTOS (стоит отметить, что вся архитектура x86 совместима с ними весьма через раз, но это другая история).
При настройках по умолчанию работающий в SMM код имеет полный доступ ко всей физической памяти на чтение и запись, полный доступ ко всем подключенным устройствам, в общем — может практически все, и при этом независим от ОС и недоступен из нее даже на чтение, что сильно затрудняет его анализ и делает код обработчиков SMI весьма привлекательной целью для атаки. Более того, если атакуемой системе доступна из SMM запись на SPI-микросхему (а она доступна во всех случаях, кроме систем с включенной PFAT, которые не найти с огнем, систем с Read-only BIOS’ом, которые встречаются еще реже, и систем с защитой через PR-регистры), то успешная атака может закончиться записью своего кода в BIOS, с последующем воровством, убийством и непотребством с гусями. Именно поэтому защитить SMM от вставки туда вредоносного кода — жизненно необходимо.
Атаки на SMM и защита от них
Забытый D_LOCK
Код в SMRAM не появляется там самостоятельно, сначала саму SMRAM нужно настроить, инициализировать физическую память, настроить TSEG так, чтобы все обработчики туда влезли, скопировать туда код SMM-диспетчера и обработчиков, настроить там таблицы дескрипторов — в общем, навести строгий уставной порядок, после чего обязательно снять бит D_OPEN, чтобы никто больше там ничего не испортил, и установить бит D_LOCK, чтобы D_OPEN нельзя было поставить назад. На некоторых старых системах установить D_LOCK забывали, и там SMM был отрыт всем ветрам, но во времена UEFI этого уже не происходит, так что этот вектор атаки ушел в историю.
SMM cache poisoning
Еще одна историческая атака — отравление кэша SMRAM, которую в 2009 году опубликовали Rafal Wojtczuk и Joanna Rutkowska. Суть атаки коротко — меняем тип памяти для региона SMRAM на Write-Back, организуем запись в регион SMRAM своего кода, запись в память не происходит, но при этом наш код остается в кэше второго уровня, после чего генерируем программное SMI и процессор читает данные не из SMRAM, а из кэша, и выполняет наш вредоносный код. Проблема решилась радикально — производители CPU запретили ставить режим WB на SMRAM, и потому системе с UEFI этой уязвимости не подвержены.
SMM call-out, она же SMM incursion attack
Please, please, please, go apply patches!
DMA attack
SMM cross-buffer attack
Представленная специалистами из Intel ATR атака на обработчики SMI, которые принимают в качестве параметра указатель и размер буфера, и производят запись в него. Атакующий может передать указатель и размер таким образом, чтобы буфер пересекал границу RAM-SMRAM, а т.к. обработчик SMI имеет доступ к SMRAM, то он перепишет какую-то часть данных вначале SMRAM. При удачном стечении обстоятельств (т.е. приблизительно после 500 часов отладки минимум) обработчик может переписать служебные структуры диспетчера SMM или других обработчиков нужным атакующему образом, и он получит возможность выполнения произвольного SMM-кода. Атака адски сложная и целевая, но вполне возможная, поэтому с начала 2015 года все обработчики SMI, принимающие указатели на буфер, обязаны валидировать его перед использованием. На более старых системах атака будет работать, но вероятность того, что именно вас через нее взломают — невелика.
Заключение
Ну вот, теперь разобрались более или менее и с SMM, в следующей части поговорим об атаках на S3 BootScript.
Спасибо за внимание, безопасных вам прошивок.
основные сведения о таблице защиты Windows SMM (WSMT)
таблица по обеспечению безопасности Windows SMM (WSMT) — это таблица ACPI, определенная корпорацией майкрософт, которая позволяет системному встроенному по проверить операционную систему на наличие определенных рекомендаций по обеспечению безопасности в программном обеспечении (SMM). определение таблицы WSMT описано в спецификации Windows таблицы мер безопасности SMM (вмст).
Историческая справка
влияние использования WSMT на поддержку Windows VBS
В поле Флаги защиты WSMT указываются сведения о наличии этих конкретных угроз безопасности SMM в встроенном программном обеспечении системы. поддерживаемые версии операционной системы Windows читать флаги защиты WSMT на ранних этапах инициализации, до запуска гипервизора и VBS, а также включать, отключать или отменять некоторые функции безопасности в зависимости от наличия этих флагов защиты SMM.
Примечания по реализации
Правильная реализация средств обеспечения безопасности, представленных флагами защиты WSMT FIXED_COMM_BUFFERS и COMM_BUFFER_NESTED_PTR_PROTECTION, требует тщательного анализа и, возможно, перепроектирования обработчиков прерываний управления системой (SMI). Все обработчики SMI должны быть ограничены доступом (для чтения или записи) к допустимым областям памяти, содержащим память MMIO и, выделенную EFI. Не вполне достаточно проверить, что указатели в SMM не ссылаются на память целиком за пределами SMM. Вместо этого все указатели SMM должны быть проверены в пределах этих областей памяти. это предотвращает использование SMM при атаке «путают deputy», которая затем может быть использована для взлома Windows VBS. Указанные выше флаги защиты относятся только к проверке входных данных и проверкам указателей, и в настоящее время не требует принудительного применения с помощью защиты страниц SMM. Например, SMM не следует считывать или записывать данные в память, которая была описана встроенным по как Ефиконвентионалмемори, поскольку она может содержать секреты или вызывать непредсказуемое поведение программного обеспечения.
Проверка защиты в WSMT
поскольку SMM непрозрачна для операционной системы, невозможно создать тест, выполняемый в Windows, чтобы убедиться, что защита, предписанная в спецификации WSMT, фактически реализована в SMM. В операционной системе единственными возможными проверками является наличие приложения WSMT и проверка состояния всех определенных флагов защиты.
Таким образом, поставщик вычислительной техники должен тщательно сопротивляются код SMM каждой системы и убедиться, что встроенное по соответствует рекомендациям, изложенным в спецификации WSMT и этой статье. Флаг защиты не должен иметь значение «true» до тех пор, пока поставщик вычислительной техники не подтвердил, что для каждого значения флага защиты были правильно реализованы все меры по устранению. если не придерживаться этого способа, это позволит оставить платформу уязвимой для компрометации и отменять эффективность нескольких средств защиты ос и Windows функции безопасности, использующие VBS для поддержания надежных границ безопасности.
Поддерживаемые версии Windows
Поддержка WSMT включена в следующие версии Windows:
Microsoft добавит новые меры безопасности UEFI в Windows 10
В прошлых публикациях, посвященных улучшениям безопасности Windows 10 [1,2,3,4], я неоднократно хвалил Microsoft за эти полезные нововведения. Новые механизмы безопасности помогают более эффективно бороться с эксплойтами. Пока очевидно, что Microsoft все больше делает ставку на новые технологии защиты от эксплойтов, основанные на виртуализации Virtualization Based Security, при этом добавляя более современные метрики безопасности и вынося выполнение критических по безопасности операций в отдельные виртуальные машины с высоким уровнем привилегий.
На сей раз речь пойдет о безопасности прошивок UEFI. Известный гуру внутреннего устройства Windows Alex Ionescu опубликовал у себя в твиттере скриншот дополнительных требований безопасности UEFI, которые должны поддерживаться прошивками начиная с Windows 10 1703. Как известно, эта версия Windows 10 и может получить название очередного существенного обновления Redstone 2.
Не секрет, что сама прошивка, ее компоненты и драйверы в современных ПК являются почти мини-ОС, которая получает управление еще до передачи упropравления загрузчику Windows. Столь стремительное распространение UEFI подталкивает security-ресерчеров к детальному поиску уязвимостей в прошивках и их драйверах, а производителей BIOS/UEFI к пересмотру механизмов их защиты. Злоумышленнику достаточно воспользоваться уязвимостью только в одном компоненте прошивки, чтобы скомпрометировать такие продвинутые VBS- технологии защиты Windows 10 как Device Guard, Credential Guard, Windows Defender Application Guard.
Одним из подобных эксплойтов, который способен компрометировать все указанные выше технологии защиты Windows 10, основанные на виртуализации (VBS) является ThinkPwn, о котором я писал здесь. ThinkPwn использует уязвимость в драйвере прошивки для того, чтобы исполнить свой код на самом привилегированном уровне — SMM.
Рис. Абстрактные уровни привилегий исполнения кода. Высший относится к Intel ME, далее SMM и гипервизор. Компрометация UEFI-прошивки позволяет компрометировать гипервизор и основанные на нем механизмы защиты (Device Guard, Credential Guard, Windows Defender Application Guard).
Очевидно, что Microsoft учла вышеприведенные причины и добавила новые требования безопасности к прошивкам UEFI. Первое требование относится к фактической реализации DEP для прошивки. Т. е. страницы памяти с данными прошивки будут помечаться как NX (non-executable), что позволит исключить исполнение кода из ненадлежащих регионов памяти.
VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.
Вторая функция безопасности относится к защите от эксплуатации уязвимостей, связанных с системной таблицей ACPI и драйверов (сервисов) UEFI. Для этого используется новая системная структура данных под названием Windows SMM Security Mitigations Table (WSMT).
The Windows SMM Security Mitigations Table (WSMT) specification contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.
Отметим, что в обоих случаях Microsoft подчеркивает, тот факт, что введенные методы безопасности обезопасят VBS от компрометации через уязвимости в прошивке.
Reduces the attack surface to VBS from system firmware