Новые механизмы смягчения в Windows 8.1

Ранее мы писали про некоторые механизмы затруднения эксплуатации (mitigation) для Windows и приложений, которые Microsoft пыталась привнести с выпуском новых ОС. Как правило подобные механизмы основываются на следующих концептуальных подходах:

• Разграничение прав доступа приложений к ресурсам ОС (User Account Control ^[1], Integrity Level ^[2]). Vista+
• Особые смягчающие факторы при работе с памятью DEP&ASLR ^[3]. XP SP2/Vista+. DEP задается системными настройками и в Windows 8+ активен для всех приложений (поддержка процессора). ASLR работает для приложений, скомпилированных с его поддержкой.
• Kernel ASLR/DEP, для компонентов, которые работают в режиме ядра. Vista SP1+. ASLR/DEP активен по умолчанию для модулей режима ядра, DEP от исполнения данных в пуле требует выделений из NonPagedPoolNx ^[4] (Windows 8+).
• Защита от перезаписи указателей на функции в SEH на уровне ОС (SEHOP). Vista SP1+. По умолчанию активен только для серверных выпусков.
• Бесплатный инструмент EMET ^[5] (v 4.1 last update) для повышения иммунитета системы от действий эксплойтов. Для Windows XP+.
• Расширенная изоляция процессов AppContainer ^[6] (aka sandboxing, расширенный Integrity Level). Windows 8+. Используется для Internet Explorer 10+ и всех приложений Modern UI aka Metro.
• Блокирование доступа к получению информации об адресах объектов ядра для недоверенных приложений (KASLR bypass mitigation ^[7]). Windows 8.1.

Последний пункт заслуживает особого внимания, поскольку такое нововведение было добавлено MS именно в Windows 8.1 как расширение для AppContainer mode или Integrity Level. Условно говоря, недоверенное приложение aka restricted caller (чей Integrity Level < Medium ^[8]) не имеет права получить информацию об адресах различных объектов в режиме ядра, что означает фактическую компрометацию ограничений KASLR и последующую возможную эксплуатацию LPE (Local Privelege Escalation). Основными функциями разглашения подобной информации были разумеется NtQuerySystemInformation с различными классами, а также NtQueryProcessInformation. Именно к этим функциям ограничен доступ для соответствующих приложений.

В случае c NtQuerySystemInformation приложению с низким Integrity Level будет возвращен STATUS_ACCESS_DENIED если он запрашивает информацию по следующим классам:

• SystemModuleInformation/SystemModuleInformationEx — адреса загруженных драйверов
• SystemLocksInformation — адреса объектов ядра (ERESOURCE)
• SystemStackTraceInformation — адрес стека режима ядра
• SystemHandleInformation/SystemExtendedHandleInformation — адреса объектов ядра
• SystemObjectInformation — адреса объектов ядра
• SystemBigPoolInformation/SystemSessionBigPoolInformation — адреса выделенной системной памяти
• SystemProcessInformation/SystemExtendedProcessinformation/SystemFullProcessInformation — адреса объектов ядра процессов, потоков и их стеков.

Рис. Точки вызова функции проверки Integrity Level в маркере доступа приложения, которое пытается получить доступ к ntoskrnl!NtQuerySystemInformation. ntoskrnl!ExpQuerySystemInformation отвечает за сбор информации для соответствующих классов, в ней и выполняется вызов функции ntoskrnl!ExIsRestrictedCaller, которая осуществляет саму проверку.

Кроме NtQuerySystemInformation доступ блокируется и к функции NtQueryInformationProcess, через которую приложение может получить доступ к адресам различных объектов. Для классов ProcessHandleTracing, ProcessWorkingSetWatch/ProcessWorkingSetWatchEx также возвращается соответствующий статус ошибки.

www.alex-ionescu.com/?p=82 ^[7]

Автор: esetnod32

Источник ^[9]