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

сегодня в 15:39

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

• Разграничение прав доступа приложений к ресурсам ОС (User Account Control, Integrity Level). Vista+


• Особые смягчающие факторы при работе с памятью DEP&ASLR. XP SP2/Vista+. DEP задается системными настройками и в Windows 8+ активен для всех приложений (поддержка процессора). ASLR работает для приложений, скомпилированных с его поддержкой.


• Kernel ASLR/DEP, для компонентов, которые работают в режиме ядра. Vista SP1+. ASLR/DEP активен по умолчанию для модулей режима ядра, DEP от исполнения данных в пуле требует выделений из NonPagedPoolNx (Windows 8+).


• Защита от перезаписи указателей на функции в SEH на уровне ОС (SEHOP). Vista SP1+. По умолчанию активен только для серверных выпусков.


• Бесплатный инструмент EMET (v 4.1 last update) для повышения иммунитета системы от действий эксплойтов. Для Windows XP+.


• Расширенная изоляция процессов AppContainer (aka sandboxing, расширенный Integrity Level). Windows 8+. Используется для Internet Explorer 10+ и всех приложений Modern UI aka Metro.


• Блокирование доступа к получению информации об адресах объектов ядра для недоверенных приложений (KASLR bypass mitigation). Windows 8.1.

Последний пункт заслуживает особого внимания, поскольку такое нововведение было добавлено MS именно в Windows 8.1 как расширение для AppContainer mode или Integrity Level. Условно говоря, недоверенное приложение aka restricted caller (чей Integrity Level < Medium) не имеет права получить информацию об адресах различных объектов в режиме ядра, что означает фактическую компрометацию ограничений 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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers.