Обзор эксплойтов

Крис Касперски

Хакер, номер #094, стр. 094-054-6

Идем дальше и загружаем в отладчик memory3.dmp, который, по утверждению johnny cache, оказал убийственное воздействие на регистр EIP. Что ж, посмотрим-посмотрим:

i386kd -z L:\dumps\crash2\memory2.dmp -logo out3

После команды «!analyze -v» отладчик выдает следующий результат, приводимый здесь с традиционными сокращениями:

Анализ дампа памяти, оказавшего воздействие на регистр EIP

kd> !analyze -v

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

Arguments:

Arg1: 5c01abf7, memory referenced

Arg2: 00000002, IRQL

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

Arg4: cccccccf, address which referenced memory

Debugging Details:

------------------

WRITE_ADDRESS: 5c01abf7

CURRENT_IRQL: 2

FAULTING_IP:

+ffffffffcccccccf

cccccccf 01963b10ffd6 add [esi+0xd6ff103b],edx

LAST_CONTROL_TRANSFER: from ff103b96 to cccccccf

STACK_TEXT:

cccccccc ff103b96 01c486d6 00000000 00000000 0xcccccccf

01c486d6 00000000 00000000 00000000 00000000 0xff103b96

На первый взгляд ничего не изменилось — все тот же противный DRIVER_IRQL_NOT_LESS_OR_EQUAL, возникающий на уровне DISPATCH_LEVEL, но присмотрись к значению регистра EIP, вылетевшему далеко за пределы драйвера и указывающего на инструкцию «add [esi+0xd6ff103b], edx», случайно очутившуюся по адресу CCCCCCCFh, который очень сильно смахивает на начинку атакующего пакета. Но почему же тогда EIP равен не CCCCCCCCh, а CCCCCCCFh, которого в пакете не было?!

Все просто! Страница с адресом CCCCCCCCh случайно оказалась в оперативной памяти и не была вытеснена на диск. Поэтому, как только пакет-камикадзе передвинул регистр EIP на адрес CCCCCCCCh, процессор начал выполнение кода, каждый раз увеличивая EIP на размер успешно выполненной команды. Он споткнулся лишь тогда, когда встретил инструкцию «add [esi+0xd6ff103b], edx», обратившуюся к ячейке 5C01ABF7h, которой не было в оперативной памяти, а подкачка на уровне DISPATCH_LEVEL, как уже говорилось, не работает, вот операционная система и сказала «мяу».

Чтобы подкрепить наше предположение фактами, травой и грибами, находясь в отладчике, дадим команду «u CCCCCCCC», чтобы дизассемблировать код по данному адресу:

Дизассемблерный листинг окрестностей аварии

kb>u cccccccc

cccccccc d6 ??? ; setalc Set AL to Carry Flag

cccccccd 86c4 xchg ah,al

cccccccf 01963b10ffd6 add [esi+0xd6ff103b],edx

ccccccd5 86c4 xchg ah,al

ccccccd7 0100 add [eax],eax

ccccccd9 0000 add [eax],al

ccccccdb 0000 add [eax],al

ccccccdd 0000 add [eax],al

Первой идет неизвестная отладчику i386kd недокументированная команда SETALC (Set Al to Carry Flag), а за ней — XCHG AH,AL. Обе эти команды выполняются успешно. Но как только процессор доходит до команды «ADD [ESI+0XD6FF103B],EDX», расположенной по адресу CCCCCCCFh и обращающейся к недоступной ячейке 5C01ABF7h, возникает исключение, и операционная система показывает голубой экран.