Аналіз захищеності технології INTEL SMEP на базі Windows 8

Обробка винятків та переривань

 

ПРОГРАМНА ПІДТРИМКА  ТЕХНОЛОГІЇ SMEP

Підтримка SMEP може бути визначена за допомогою інструкції "cpuid". Результат виконання запиту "cpuid" для рівня 7 з підрівнем 0 (вхідні параметри EAX = 7, ECX = 0) вказує на підтримку SMEP на даному процесорі - для цього необхідно перевірити 7-й біт регістра EBX. 64-розрядна версія Windows 8 перевіряє підтримку SMEP при ініціалізації завантажувальних структур, заповнюючи змінну "KeFeatureBits":

KiSystemStartup () → KiInitializeBootStructures () → KiSetFeatureBits ()

Те  ж саме відбувається в x86 версії Windows 8:

KiSystemStartup () → KiInitializeKernel () → KiGetFeatureBits ()

Змінна "KeFeatureBits" в подальшому використовується при обробці помилок сторінок. Якщо процесор підтримує технологію SMEP, ОС включає її, встановлюючи 20-й біт регістра CR4. На x86 версії вона включається також під час старту системи, в фазі 1 у функції KiInitMachineDependent () і потім ініціалізується для кожного ядра процесора, ініціюючи міжпроцесорних переривання, яке в підсумку викликає функцію KiConfigureDynamicProcessor (). Те ж саме відбувається на x64 версії ОС, за винятком того, що в ній відсутня функція

KiInitMachineDependent (). Таким чином, включення SMEP і ініціалізація змінної "KeFeatureBits" відбувається при старті системи. Іншою частиною програмної підтримки SMEP є код обробника помилок сторінок. У Windows 8 була додана нова функція - MI_CHECK_KERNEL_NOEXECUTE_FAULT (). Всередині неї відбувається перевірка на порушення технологій SMEP і NX. Якщо відбулося порушення прав доступу, пов'язане з SMEP або NX, то ОС показує користувачеві сінійекран смерті з кодом помилки

"ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY":

KiTrap0E () / KiPageFault () → MmAccessFault () → ... →

→ MI_CHECK_KERNEL_NOEXECUTE_FAULT ()

Дана  функція реалізована тільки в  Windows 8.

 

 СПОСОБИ ОБХОДУ SMEP НА ОС WINDOWS І ПРОТИДІЯ ЙОМУ

Логічно припустити, що якщо не можна зберігати  шелл-коду в користувальницькому адресному просторі, необхідно знайти спосіб його впровадження в простір ядра. Найбільш очевидним рішенням в даному випадку є використання об'єктів Windows, таких як WinAPI (таймери, події, секції і т.д.) або GDI (контексти пристроїв, палітри і т.д.). Доступ до них здійснюється непрямим чином через функції WinAPI, які в свою чергу використовують системні виклики. Суть в тому, що тіло об'єкту зберігається в пам'яті ядра, а його поля можуть бути змінені в режимі користувача. Таким чином, атакуючий здатний передати необхідні байти шелл-коду з простору користувача в простір ядра. Також очевидно, що атакуючому необхідно знати, де саме в просторі ядра знаходиться тіло використовуваного ним об'єкта. Для цього необхідний метод розкриття інформації про просторі ядра, оскільки, як ми пам'ятаємо, користувальницькому додатком недоступні страніципамяті ядра, в тому числі і для читання. Такі методи існують в ОС Windows [2].

З описаного вище випливає, що теоретично можливо обійти SMEP завдяки розкриттю інформації про просторі ядра в ОС Windows. Однак SMEP доповнюється таким механізмом захисту, як використання пулів, помічених як неісполняемимі, для виділення пам'яті для об'єктів в Windows 8. У рамках даної роботи були перевірені на придатність для впровадження шелл-коду в простір ядра різні об'єкти Windows. Об'єкти WinAPI зберігаються в підкачувати і неподкачіваемом пулах. Об'єкти GDI зберігаються в підкачувати пулі сесії (session pool). Всі вони є неісполняемимі в Windows 8. Більш того, відповідно до результатом сканування таблиць сторінок кількість використовуються сторінок з виконуваних пулів тепер вкрай мало. Всі буфери даних тепер є неісполняемимі. Більшість виконуваних сторінок (наприклад, образи драйверів) недоступні для запису.

Недолік конфігурації

Як  згадувалося вище, всі об'єкти в  Windows 8 тепер зберігаються в невиконуваних пулах. Це твердження справедливе для х64 версії і частково для х86 версії ОС. Недоліком є ​​пул сесії. Він позначений як виконуваний на x86 версії Windows 8. Отже, можна використовувати відповідний об'єкт GDI для зберігання шелл-коду в пам'яті ядра. Найбільш підходящим об'єктом для цієї мети є GDI Palette - об'єкт палітри. Він створюється за допомогою функції CreatePalette () і відповідної заповненої структури LOGPALETTE. Дана структура містить в собі масив структур PALETTEENTRY, які визначають кольори і їх використання в логічній палітрі [5]. Сенс у тому, що на відміну від інших об'єктів GDI при створенні палітри немає валідації на вміст масиву кольорів. Атакуючий може зберігати будь-які кольори в своїй палітрі. Таким же чином він може зберігати байти шелл-коду. Адреса тіла об'єкта палітри може бути отриманий за допомогою розділяється таблиці GDI. Вміст палітри зберігається по деякому зміщенню (в нашому випадку 0x54). Однак даний зсув знати не обов'язково, оскільки шелл-код можна зберігати де-небудь після заповнення палітри інструкціями NOP. Схема обходу SMEP представлена ​​на малюнку 1.

Малюнок 1. Схема обходу SMEP на x86 версії Windows 8

Об'єкт  палітри надає достатню кількість  байт для зберігання об'ємного шелл-коду. Однак насправді все, що потрібно атакуючому, це відключити SMEP. Це можна зробити простим скиданням 20-го біта керуючого регістру CR4, після чого атакуючий отримає можливість виконання коду з користувальницького буфера вже без будь-яких обмежень на размер.Разумеется, при використанні пулу сесії існують деякі обмеження. По-перше, він є підкачувати, отже, необхідно враховувати рівень запиту на переривання (IRQL) при експлуатації уразливості режиму ядра. По-друге, пул сесії проектується відповідно до поточної користувальницької сесією, значить, також необхідно враховувати поточну сесію. І по-третє, в багатопроцесорної середовищі керуючі регістри присутні на кожному ядрі, отже, необхідно використовувати прив'язку потоку до ядра для відключення SMEP на конкретному ядрі процесора.

Практична реалізація

Наприклад, коли ми відкриваємо файл функцією CreateFile (), ми отримуємо дескриптор відкритого файлу. Якщо додатком потрібно вважати пару байт цього файлу  в буфер, то ми викликаємо функцію ReadFile (), яка за допомогою системного виклику  передає управління в ядро ​​ОС, де за таблицею описувачів знаходить  потрібний об'єкт файлу. В даному випадку об'єкт має тип _FILE_OBJECT, і змінним полем в ньому  є ім'я файлу. Тобто теоретично можна створити файл з ім'ям "xBAADC0DE", яке буде містити наш шелл-код. Потім ми експлуатуємо якусь уразливість  режиму ядра і передаємо управління на наш шелл-код.

 

0: kd> dt nt! _FILE_OBJECT

+0 × 000 Type: Int2B

+0 × 002 Size: Int2B

...

+0 × 050 Flags: Uint4B

+0 × 058 FileName: _UNICODE_STRING

+0 × 068 CurrentByteOffset: _LARGE_INTEGER

...

+0 X0c0 IrpList: _LIST_ENTRY

+0 X0d0 FileObjectExtension: Ptr64 Void

 

Успіх? Поки ще не зовсім. Справа в  тому, що SMEP на Windows 8 доповнюється іншим  механізмом захисту. Незважаючи на те, що код розташований на сторінці режиму ядра, ця сторінка має позначку (біт NX) про те, що вона не виконувана, тобто на цій сторінці не може виконуватися код! Виходить, що об'єкти Windows захищені від виконання, отже, теж не підходять для зберігання шелл-коду. Це твердження вірне для х64 версії Windows 8. Однак в x86 версії тіла графічних об'єктів розташовуються у виконуваній пам'яті!

Найбільш підходящим об'єктом для  доставки шелл-коду виявилася палітра. Створюється вона за допомогою функції CreatePalette () і структури LOGPALETTE, вміст якої і наповнюється шелл-кодом. Ще б пак, як валідувати кольору в палітрі? Адже в нашій палітрі будуть саме ті кольори, які ми захочемо! А ми захочемо багато байт NOP (0 × 90), і багато байт шелл-коду. Ось така виходить «зла» палітра ...

Разом маємо схему обходу SMEP на Windows 8 x86:

1. Створюємо «злу» структуру LOGPALETTE, наповнюючи її шелл-кодом.

2. Створюємо палітру через CreatePalette ().

3. Знаходимо адресу об'єкта палітри  в ядрі через поділювану таблицю  GDI.

4. Передаємо управління по деякому  зміщення від об'єкта палітри.

5. PROFIT!

х64

Обхід SMEP на Windows 8 x64. SMEP на x64 обходиться за допомогою зворотно-орієнтованого  програмування (ROP). ROP використовує вже  присутні в пам'яті ділянки коду з інших модулів. Таким чином, прокидати свій шелл-код в ядро ​​не потрібно.

Звичайно, можливості атакуючого при  складанні корисного навантаження в даному випадку сильно обмежені. Але все, що потрібно атакуючому - відключити SMEP, а для цього в модулі «ntoskrnl»  є «подаруночки» у вигляді  функцій HvlEndSystemInterrupt () і KiConfigureDynamicProcessor (). Останні байти цих функцій  дозволяють відключити SMEP на заданому процесорі.

 

HvlEndSystemInterrupt ():

...

pop rax

pop rcx

retn

KiConfigureDynamicProcessor ():

...

mov cr4, rax

add rsp, 28h

retn

/ / ROP chain to refresh cr4 value

 

/ / VTrash vROPChain

DWORD_PTR dwRopStack [7 + 10] = {0};

 

/ / HvlEndSystemInterrupt gadget

dwRopStack [7 + 0] = dwKernelBase + HvlGadgetOffset;

/ / New CR4 value

dwRopStack [7 + 1] = 0x00000000000506F8;

/ / KiConfigureDynamicProcessor

dwRopStack [7 + 3] = dwKernelBase + Cr4GadgetOffset;

/ / Out address (shellcode)

dwRopStack [7 + 9] = (DWORD_PTR) pTestBuf;

Інші напрямки атак для обходу SMEP

Як  згадувалося вище, зворотно-орієнтоване  програмування може успішно використовуватися для обходу засобів захисту SMEP, оскільки в даному варіанті необов'язково зберігати підготовлений заздалегідь шелл-код. Замість цього можна використовувати фрагменти коду, які вже зберігаються в пам'яті ядра (наприклад, драйвера). Також існує можливість експлуатації драйверів сторонніх виробників, які поки не використовують невиконуємі пули для зберігання даних.

 

ВИСНОВОК

У даному корсовому проекті був описаний принцип роботи технології Intel SMEP і її програмна підтримка в Windows 8. Також був показаний варіант обходу даної технології в певних випадках зважаючи на можливість розкриття інформації про адресний простір ОС і часткового застосування механізмів захисту. Тим не менш, в тому вигляді, в якому реалізована підтримка SMEP на x64 версіях Windows 8, вона може вважатися достатньо надійною та здатною запобігти різні атаки з використанням вразливостей режиму ядра.

 

 

ВИКОРИСТАНА ЛІТАРЕТУРА ТА РЕСУРСИ

1. [1] Intel: Intel® 64 and IA-32 Architectures Developer's Manual: Combined Volumes. Intel Corporation, 2012.
2. [2] Mateusz “j00ru” Jurczyk: Windows Security Hardening Through Kernel Address  Protection. 

http://j00ru.vexillium.org/blog/04_12_11/Windows_Kernel_Address_Protection.pdf

3. [3] Mateusz  “j00ru” Jurczyk, Gynvael Coldwind:  SMEP: What is it, and how to beat it on Windows. http://j00ru.vexillium.org/?p=783
4. [4] Ken Johnson, Matt Miller:  Exploit Mitigation Improvements in Windows 8. Slides, Black Hat USA, 2012.
5. [5] MSDN:  Windows GDI.

http://msdn.microsoft.com/enus/library/windows/desktop/dd145203(v=vs.85).aspx

6. [6] Feng Yuan: Windows Graphics Programming Win32 GDI and DirectDraw®. Prentice Hall PTR, 2000.
7. [7] Mark Russinovich, David A. Solomon, Alex Ionescu: Windows® Internals: Including Windows Server 2008 and Windows Vista, Fifth Edition. Microsoft Press, 2009.
8. http://lenzfire.com/2011/09/intel-introduces-smep-for-ivy-bridge-a-new-security-feature-80649/ Intel Introduces SMEP for Ivy Bridge, A New Security Feature
9. http://www.pvsm.ru/windows/15936/print/ Windows 8 – да будет SMEP!
10. http://www.intel.ua/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 3A 
11. http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BB%D1%8C%D1%86%D0%B0_%D0%B7%D0%B0%D1%89%D0%B8%D1%82%D1%8B -- Кольца защиты
12. http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B6%D0%B8%D0%BC_%D1%81%D1%83%D0%BF%D0%B5%D1%80%D0%B2%D0%B8%D0%B7%D0%BE%D1%80%D0%B0 -- Режим супервизора
13. http://ru.wikipedia.org/wiki/CPUID -- CPUID (CPU Identification) 
14. http://www.ptsecurity.ru/download/Technology_Overview_Intel_SMEP_and_partial_bypass_on_Windows_8.pdf -- Positive Research -- Обзор технологии Intel SMEP и её частичный обход на ОС Windows 8