Windows smm security mitigations table что

Обновлено: 04.07.2024

Данная статья продолжает тему углубленного исследования платформы PC,
архитектуры x86 и связанных с ними современных технологий. Рекомендации по
организации рабочего места, объяснение, почему именно DOS выбрана в качестве
полигона для исследований, комментарии по использованию устройства POST Card при
отладке программ, а также описание целевой аудитории содержатся в ранее
опубликованной статье “64-битный
режим под DOS: исследовательская работа № 1”.

Разделы 1-7 содержат теоретические сведения. Опытный специалист может
начинать чтение с раздела 8, в котором на ассемблерном уровне рассматривается
практический пример – считывание блока из SMRAM и сохранение в виде двоичного
файла.

История вопроса

Режим System Management Mode (SMM) как специальное состояние
процессора, используемое для выполнения функций по управлению платформой,
появился в процессорах Intel и AMD в середине 90-х годов прошлого века.
“Улучшенные” модификации процессоров класса 486 уже поддерживали этот режим. Для
использования SMM, часть системного ОЗУ выделяется под System Management RAM
(SMRAM). SMRAM используется для хранения выполняемого кода процедур
поддержки SMM, сохранения и восстановления состояния процессора при переходе в
режим SMM и выходе из него, хранения переменных, связанных с поддержкой SMM, а
также других целей, набор которых определяет разработчик BIOS. Процессор
переходит в режим SMM при получении сигнала запроса на прерывание System
Management Interrupt (SMI), генерируемого специальными схемами системной
платы при наступлении контролируемых событий.

Режим SMM был разработан для управления такими объектами и событиями в
системе, существование которых требовалось “скрыть” от ОС, в рамках концепции
взаимодействия ОС и оборудования, характерной для того этапа развития платформы
PC. Такая постановка задачи определила следующие характерные особенности
архитектуры SMM: для хранения адреса процедуры обработки аппаратного прерывания
SMI не используется ни один из векторов в стандартной таблице векторов, в
отличие от всех остальных прерываний. Вместо этого, адрес хранится в специальных
регистрах процессора. Для сохранения и восстановления состояния процессора при
обработке прерывания SMI, не используется стандартный стек, вместо этого
используется память SMRAM, в которой хранятся все данные, необходимые для
поддержки SMM.

Когда BIOS передает управление на загрузку ОС, он настраивает чипсет (в
частности схемы картирования памяти) таким образом, что память SMRAM недоступна
в адресном пространстве. В большинстве платформ для картируемого доступа к SMRAM
используется 128Кбайтное окно по адресам 000A0000h-000BFFFFh. Когда процессор
находится в обычном режиме (не SMM), данный диапазон отображается на шину
ввода-вывода и используется для чтения и записи памяти видеоадаптера. По сигналу
SMI, процессор переходит в режим SMM, после этого на тот же диапазон адресов
будет включена оперативная память (область SMRAM), доступ к видеопамяти временно
закрывается. При выходе из режима SMM после завершения обработки прерывания SMI,
на выше указанный адресный диапазон снова будет включена видеопамять. Таким
образом, память SMRAM “не видна” для ОС и программ.

Внимательный читатель может задать вопрос: а как быть, если процедуре
обработки SMI, выполняемый код которой находится в диапазоне
000A0000h-000BFFFFh, требуется выполнить запись в видеопамять? Для этого,
программно-управляемая логика картирования обеспечивает дополнительную гибкость,
например, процедура обработки SMI может временно включить режим, при котором
процессорные циклы чтения выполняемого кода в диапазоне 000A0000h-000BFFFFh
направляются на SMRAM, а циклы чтения и записи данных направляются на
видеопамять. Есть и другое решение, которое обусловлено тем, что практически все
современные видеоадаптеры, помимо постраничного доступа к видеопамяти в
диапазоне 000A0000h-000BFFFFh обеспечивают и линейный (плоский) доступ к ней в
диапазоне, находящемся выше 1MB. Адрес и размер этого диапазона устанавливается
механизмами PCI PnP. Использование такого метода не создает рассмотренного выше
конфликта адресов в режиме SMM.

Сферы применения режима SMM

Как было сказано выше, режим SMM был разработан для управления такими
объектами и событиями в системе, существование которых требуется “скрыть” от ОС.

Сразу после появления SMM, одной из основных сфер его применения являлся
Power Management, осуществляемый BIOS. При наступлении событий, связанных с
взаимодействием программного обеспечения и оборудования (обращение программ к
заданным портам, генерация прерываний), специальная логика, обычно входящая в
состав чипсета системной платы, генерирует прерывание SMI, процедура обработки
которого, входящая в состав BIOS, собирает статистику использования различных
устройств. На основании результатов этой статистики, устройства, не используемые
в течение заданного интервала времени, отключались. Этим обеспечивалось снижение
общей потребляемой мощности системы. Необходимо отметить, что на сегодня, данная
сфера применения SMM уже не актуальна, так как Power Management в современных
платформах и ОС базируется на спецификации ACPI, которая возлагает на ОС все
обязанности по оптимизации энергопотребления. При этом вместо “спрятанного от
ОС” прерывания SMI, генерируется SCI (System Control Interrupt), которое
использует стандартный контроллер прерываний и таблицу векторов. Подробности в
[19].

Другая сфера применения SMM – эмуляция физически несуществующего
оборудования. Например, есть много DOS программ, которые для ввода с клавиатуры
используют чтение скан-кодов из порта данных контроллера клавиатуры (0060h)
вместо вызова сервисных процедур BIOS. Несмотря на очевидное ухудшение
совместимости, программисты часто использовали такое решение, так как не все
комбинации клавиш можно адекватно распознать, используя сервис BIOS. “Час
расплаты” наступил, когда появились клавиатуры USB, при использовании которых,
скан-код уже не доступен через порт 0060h. Разработчики платформ использовали
SMM для решения возникшей проблемы и обеспечения совместимости USB клавиатур с
DOS средой. При вводе скан-кода по интерфейсу USB, контроллер USB генерирует
SMI. Процедура обработки SMI, входящая в состав BIOS, принимает введенный код и
используя специальную команду контроллера клавиатуры (эмуляция ввода), помещает
его в буфер контроллера. После этого, обработка SMI завершается, а для
программного обеспечения все выглядит так, как при использовании стандартной
клавиатуры: скан-код доступен через порт 0060h и контроллер клавиатуры
генерирует прерывание (IRQ1).

BIOS Setup предоставляет опции для включения эмуляции PS/2 клавиатуры и мыши.
Обычно они называются Keyboard Legacy Support, Mouse Legacy Support.

Как было показано выше, режим SMM и прерывание SMI обеспечивают достаточно
хорошую изоляцию между прерываемой и прерывающей процедурой (не используются
таблица векторов прерываний, стек, обычная оперативная память), поэтому данная
технология может быть применена для написания различных программ мониторинга,
перехвата событий, отладчиков и т.п. Но при этом следует понимать, что
архитектура некоторых системных ресурсов, используемых для поддержки SMM
(например, регистров чипсета) может быть различной в различных платформах.
Поэтому, программа, работающая с SMM, будет совместима только с теми
платформами, поддержку которых предусмотрел разработчик. Еще одна проблема
состоит в том, что регистры процессора и чипсета, управляющие SMM, поддерживают
функцию LOCK, позволяющую запретить изменение состояния указанных регистров,
установив для них статус Read Only, который будет снят только после аппаратного
сброса. Если BIOS, до передачи управления на загрузку ОС, активирует функцию
LOCK (на большинстве платформ, протестированных автором, этого не происходит),
то вмешательство внешней программы в работу SMM, а также чтение и запись SMRAM
внешней программой будут невозможны.

Функции компонентов платформы.

Систематизируем выше сказанное. Итак, поддержка SMM сводится к следующей
функциональности процессора, контроллера памяти, подсистемы ввода-вывода и BIOS.

Примечание 1. Для систем AMD64 (Socket 754/939/940/AM2/AM3), у которых
контроллер памяти находится в составе процессора, описанные в этом пункте
функции, реализованы в составе процессора. Для остальных систем – в составе
“северного моста” чипсета. Подробности в [6], [13], [14], [15].

Расширенные реализации. Диапазоны ASeg, TSeg

В данной статье и приведенных далее примерах, при рассмотрении доступа к
памяти SMRAM, используется диапазон адресов 000A0000h-000BFFFFh, расположенный
ниже 1MB (A-Segment). Вместе с тем, современные платформы также поддерживают
доступ к SMRAM в диапазоне адресов выше 1MB (T-Segment). Его планируется
рассмотреть в последующих публикациях. Подробности в [6], [13] ,[14], [15].

Замечания по совместимости

Необходимо помнить, что архитектура рассматриваемых ниже регистров
контроллера памяти различается в различных платформах. Поэтому рассмотренные
ниже примеры работоспособны только для указанных чипсетов и процессоров. В
приведенном примере, автор не ставил задачу создания универсальной программы
работы с SMRAM, так как пример получился бы слишком громоздким: потребуется база
данных по всем чипсетам и процессорам. Вместе с тем, заинтересованный читатель
может добавить в приведенный исходный текст поддержку своей платформы. Напомним,
что для систем AMD64 (Socket 754/939/940/AM2/AM3), у которых контроллер памяти
находится в составе процессора, для управления SMRAM нужна поддержка различных
типов процессоров. Для остальных систем – различных типов “северных мостов”
чипсетов. Своеобразным исключением является платформа AMD Socket A (синоним
Socket 462). Контроллер памяти здесь находится в составе “северного моста”
чипсета и трансляцией процессорных обращений на шину памяти и шину ввода-вывода
управляет “северный мост”. Но выбор одной из двух этих шин осуществляется в
соответствии с MTRR (Memory Type Range Registers) атрибутами, которые
формируются на основании содержимого MTRR-регистров процессора и передаются от
процессора к чипсету. Поэтому для управления картированием памяти SMRAM на
данных платформах программировать требуется регистры процессора, несмотря на то,
что контроллер памяти находится в чипсете. Подробности в [6], [13], [14], [15].

Источники информации

16) Winbond LPC I/O W83627THF.

17) IT8712F Environment Control – Low Pin Count Input/Output (EC-LPC I/O).

18) PCI BIOS Specification. Revision 2.1.

Электронные документы, доступные на сайте
acpi.info.

19) Advanced Configuration and Power Interface Specification. Hewlett-Packard
Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies
Ltd., Toshiba Corporation. Revision 3.0.

Книги

20) В.Л. Григорьев. Микропроцессор i486. Архитектура и программирование.
Москва ТОО “ГРАНАЛ” 1993.
21) В.Г. Артюхов, А.А. Будняк. В.Ю. Лапий. С.М. Молявко, А.И. Петренко.
Проектирование микропроцессорной электронно-вычислительной аппаратуры.
Справочник. Киев “Тэхника” 1988.
22) К. Г. Самофалов, О.В. Викторов. Микропроцессоры. Библиотека инженера. Киев
“Тэхника” 1989.
23) 2B ProGroup: В.А. Вегнер, А.Ю. Крутяков, В.В. Серегин, В.А. Сидоров, А.В.
Спесивцев. Аппаратура персональных компьютеров и ее программирование. IBM
PC/XT/AT и PS/2. Москва “Радио и связь” 1995.

В прошлых публикациях, посвященных улучшениям безопасности 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 от компрометации через уязвимости в прошивке.

2017-03-04 в 14:50, admin , рубрики: информационная безопасность, метки: security, Windows 10

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.

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.

Reduces the attack surface to VBS from system firmware

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

На уровне аппаратного обеспечения – (DEP, MPX, CFI, SMEP, SMAP, UMIP, …).
На уровне операционной системы – реализовано создателями ОС. Например, SEHOP, ForceASLR. В случае ОС Linux может быть еще выполнено в виде дополнительного патча (Grsecurity).
На уровне компилятора/линковщика – stack cookie, SafeSEH.
На уровне приложения:
Стороннего – EMET, Malwarebytes Anti-Exploit, HitmanPro, PaX и подобные реализации в различных антивирусах;
Встроенного – реализовано прямо в исходном коде приложения.

Усложнить (понизить стабильность техники)
Сделать невозможной работу какой-то техники (Противодействие конкретной технике)
Смягчить последствия (Изоляции от остальной системы, sandbox)

“Exploit Mitigation Improvements in Windows 8” с BlackHat USA 2012
“WINDOWS 10 MITIGATION IMPROVEMENTS” с BlackHat USA 2016

Данный цикл статей как раз и будет посвящен последней категории, т.н. app specific security mitigations. Появление этих механизмов обусловлено самой функциональностью приложения и особенностями его реализации, как правило, затрагивающими или реализующими собственные абстракции манипулирования памятью: собственная ВМ, собственный менеджер кучи, собственный скриптовый язык и т.д.

Браузеры
Редакторы документов (Word)
Виртуальные машины (JVM, Dalvik VM, ActionScript VM)

Поскольку браузеры — самые яркие (и, наверное, самые интересные) представители ПО, реализующие собственные механизмы безопасности от эксплуатации уязвимостей класса memory corruption, мы решили в нашем исследовательском центре сосредоточиться на них. Цикл статей будет посвящен: IE + Edge, Chrome и Firefox для настольных ПК под управлением ОС Windows на x86/x64 архитектуре. Список этих механизмов был взят из обновляемой подборки «Browser security mitigations against memory corruption vulnerabilities» : нашего друга Артура Геркиса , за что ему большое спасибо.

В 2011 году компания Accuvant LABS выпустила документ «Browser Security Comparison: A Quantitative Approach» , но уже много воды утекло с того момента, и браузеры серьезно изменились. Однако, ознакомиться с этой информацией все равно не лишне.

предотвращение непредусмотренного выполнения кода или данных
предотвращение проблем, связанных со временем жизни объекта
сохранение целостности кода, данных или метаданных
ограничение информации об адресном пространстве
ограничение возможностей атакующего (sandbox)

Для тех, кто хочет более подробно ознакомиться с успешными эксплоитами для браузеров, советуем обратить внимание на выступление “$HELL ON EARTH: FROM BROWSER TO SYSTEM COMPROMISE” ( презентация и whitepaper ) с BlackHat LasVegas 2016.

Как можно заметить, даже такие “бронированные” программы успешно атакуются с обходом всех механизмов защиты как ОС, так и их собственных. В итоге, исследователи обходят с десяток механизмов безопасности – в действительности, конечно, меньше, так как это сильно зависит от типа используемых уязвимостей. Например, не обходятся механизмы stack cookie с SafeSEH, SEHOP, если уязвимость UaF — поскольку природа уязвимости никак не связана со стеком, и данные механизмы не задействованы. Самую большую угрозу для браузеров представляют уязвимости типа use-after-free (UaF) — CWE-416 – тут все обусловлено сложностью браузеров. Поэтому неудивительно, что разработчики трудятся над созданием механизмов защиты, ориентированных на противодействие данному типу уязвимостей. Следующий момент, которому уделено также пристальное внимание (с точки зрения безопасности) создателями браузеров, это написание JIT (just-in-time) кода. Это связано с тем, что атакующий может использовать такой код для расположения своего шеллкода внутри JIT spray, который одновременно позволяет обойти как DEP, так и ASLR. Поэтому разработчики и стали «закручивать гайки» в этом направлении. Об этом мы также поговорим позже.

Важно понимать, что у любого атакующего есть определенные цели, и он будет к ним идти по пути наименьшего сопротивления. Так, например, не всегда ему нужно выполнять свой собственный шеллкод и закрепляться в системе, получая доступ к данным других приложений. Если в этом нет необходимости, то не нужно обходить CFG и sandbox. При этом, он способен похитить какие-то данные доступные/хранимые браузером, или задействовать его же стандартный функционал, но в своих целях (например, подмена данных или изменение настройки браузера).

Все постепенно идет к тому, что при наличии у атакующего RW-примитива (уязвимости или ряда уязвимостей, позволяющих ему читать и писать в память), все текущие механизмы защиты обходятся.

CWE-401 : Improper Release of Memory Before Removing Last Reference ('Memory Leak')
CWE-123 : Write-what-where Condition — write-what-where memory corruption примитива

Не контролируется, то что пишется
Возможно писать только NULL
Возможно только инкрементировать значение
Как-то ограничен диапазон адресов, куда мы можем писать

В цикле статей мы рассмотрим более специфичные техники обходов механизмов браузеров.

Уязвимости класса memory corruption были, есть и будут и их будут продолжать эксплотировать. Единственное со временем это все становится сложнее. И очень много зависит от природы уязвимости. Так что на компилятор, ОС, надейся, а сам не плошай.

Читайте также: