По следам MS IE OBJECT tag exploit'а

         

Начинаем копать


Свой лог Др.Ватсон хранит в папке Documents&Settings\AllUsers\Документы\DrWatson, туда же попадает дамп памяти упавшего приложения. Дамп перезаписывается каждый раз, а лог по умолчанию сохраняет данные о 10 последних ошибках, в которые входят и сбои, вызванные нашими exploit'ми.

Открывем drwtsn32.log в FAR'е по <F4> и ищем строки, относящиеся к сбою в IE (см. листинг 4), произошедшему в заданное время (мы ведь не забыли посмотреть на часы, верно?)

Исключение в приложении:

       Прил.: iexplore.exe (pid=884)

       Время: 09.05.2006 @ 16:41:36.734

Листинг 4 при регистрации ошибки Доктор Ватсон запоминает время ее возникновения

Пропуская бесполезную информацию о запущенных процессах и загруженных динамических библиотеках, мы добираемся до дизассемблерного кода, расположенного в окрестностях сбоя exploit'а iedie2-2:

eax=0000001a ebx=0000001a ecx=01460610 edx=75b2c198 esi=01460610 edi=00000000

eip=75ad7e2e esp=0006da58 ebp=00000000 iopl=0   nv up ei pl nz na pe nc

       75ad7e23 e81b000000  call   DllGetClassObject+0x1f573 (75ad7e43)

       75ad7e28 8bd8        mov    ebx,eax

       75ad7e2a 3bdd        cmp    ebx,ebp

       75ad7e2c 740e        jz     DllGetClassObject+0x2806c (75ae093c)



СБОЙ ->       75ad7e2e 8b7b34      mov    edi,[ebx+0x34]       ds:00a7d5f0=????????

       75ad7e31 c1ef02      shr    edi,0x2

       75ad7e34 3bfd        cmp    edi,ebp

       75ad7e36 0f8fcf431300      jnle   75c0c20b

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name

00000000 00000000 00000000 00000000 00000000 00000000 mshtml!DllGetClassObject

Листинг 5 фрагмент дизассемблерного листинга Др. Ватсона, описывающего сбой IEdie2-2

Давайте, как археологи, попробуем восстановить хронологию событий и выяснить, что же здесь проиcходило. Нам известно, что инструкция MOV EDI, [EBX+0X34], расположенная по адресу 75AD7E2Eh и лежащая глубоко в недрах MSHTML.DLL, вызвала исключение типа нарушение доступа, поскольку регистр EBX содержал 1Ah, то есть указывал на первый 64 Кбайт регион памяти, доступ к которому строго запрещен как раз для отлова таким некорректных указателей.
Но откуда в EBX взялись эти злощастные 1Ah? Поднимаясь по дизассемблерному листингу вверх, мы находим инструкцию MOV EBX, EAX, копирующую содержимое EAX в EBX. Значение самого же EAX возвращается функцией DllGetClassObject+0x1f573, расположенной по адресу 75AD7E43h. Важно понять, что к самой DllGetClassObject

никакого отношения она не имеет! Просто, не найдя символьной информации, Др. Ватсон взял адрес ближайшей известной ему функции и назначил его в качестве базового.

Кое-что начинает проясняться. Функция 75AD7E43h должна возвращать указатель на структуру данных, по смещению 34h от начала которой лежит еще один указатель, но накурившись exploit'а она возвратила какую-то хрень. Напоминаю, что сбой произошел при закрытии IE, то есть, когда обработка HTML-кода уже была завершена. Следовательно, сама функция 75AD7E43h тут не причем (ее можно даже не дизассемблировать) и причину следует искать в разрушении структур данных, с которыми эта функция работает.

Теперь исследуем сбой, относящийся к IEdie2-3, дизассемблерные окрестности которого выглядят так:

eax=00000000 ebx=000af334 ecx=00000428 edx=01340294 esi=01480007 edi=01481990

eip=75acc4da esp=0006dba0 ebp=0006dbcc iopl=0   nv up ei pl nz na pe nc

функция: <nosymbols>

       75acc4bd 60          pushad

       75acc4be 8501        test   [ecx],eax           ds:00000428=?????

       75acc4c0 56          push   esi

       75acc4c1 8bf1        mov    esi,ecx

       75acc4c3 e8555cfcff  call   75a9211d

       75acc4c8 668b766c    mov    si,[esi+0x6c]        ds:01efd5de=????

       75acc4cc 6685f6      test   si,si

       75acc4cf 7418        jz     DllGetClassObject+0x14b19 (75acd3e9)

       75acc4d1 0fb7ce      movzx  ecx,si

       75acc4d4 69c998000000      imul   ecx,ecx,0x98

СБОЙ ->       75acc4da 8b8020040000      mov    eax,[eax+0x420]      ds:00000420=??????

       75acc4e0 5e          pop    esi

       75acc4e8 c3          ret

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name



0006DBCC 75A92F0F 00000001 00000000 0006DC44 000AF23C mshtml!DllGetClassObject

Листинг 6 фрагмент дизассемблерного листинга Др. Ватсона, описывающего сбой IEdie2-3

Адрес сбоя совсем другой (75ACC4DAh против 75AD7E2Eh), но библиотека вся та же — MSHTML.DLL, да и хронология событий очень похожа на предыдущую. Исключение вызывает инструкция MOV EAX,[EAX+0X420]

c регистром EAX, равным нулю, возвращенным функцией 75A9211Dh (см. CALL 75A9211D), которая по идее должна возвращать указатель на объект или структуру данных, но не возвратила, а не возвратила потому, что память была разрушена!

Что же касается IEdie2-4, то он полностью повторяет листинг 6, только регистры EBX, ECX, ESI и EDI немного другие. Это, конечно, важный факт, но пока мы не знаем, как его интерпретировать.

Еще у нас имеется дамп user.dmp, сброшенный IE перед смертью. Дамп можно загрузить в отладчик WinDbg (file à open crush dump), входящий в состав DDK, однако, ничего нового мы не узнаем (см. рис. 6). Дамп — это мертвое тело, это труп программы. Команды трассировки в нем не работают и все, что мы можем — это просматривать память, стек и регистры, которые мы и так знаем (спасибо отчету Др. Ватсона). Гораздо большие перспективы отрывает дизассемблирование MSHTML.DLL и живая отладка по месту падения (just-in-time debugging), чем мы сейчас и займемся.



Рисунок 6 дамп IE, загруженный в WinDbg


Содержание раздела