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

Предварительное расследование


Все эксперименты с exploit'ми лучше всего проводить на отдельной машине, запущенной, например, под VM Ware. Мы будем использовать: Windows 2000 SP 0 и IE 5.00.2920. Остальные версии IE валятся аналогичным способом, отличаясь лишь адресами.

Запускам Оперу или ReGet и сохраняем первый proof-of-concept exploit на диск: http://lcamtuf.coredump.cx/iedie2-1.html

(в принципе, сохранять можно в том числе и самим IE, но только сохранять, не нажимая на ссылку!). Открываем файл в FAR'е по <F3> и смотрим, что у нас там (см. листинг 1):

<STYLE></STYLE>

<OBJECT>

Bork

...

<STYLE></STYLE>

<OBJECT>

Bork

Листинг 1 исходный код exploit'а IEdie2-1.html

Хм, просто много вложенных (то есть незакрытых) тегов OBJECT, разделенных загадочным именем Bork, являющимся к тому же торговой маркой компании, производящей бритвы. Ладно, оставим бритвы в покое, и проверим реакцию exploder'а. IE 5.0 спокойно переваривает наживку, отображая ее как родную.



Рисунок 3 реакция IE 5.0 на IEdie2-1 – все отображается нормально

Со вторым exploit'ом (http://lcamtuf.coredump.cx/iedie2-2.html) нам везет куда больше. На первый взгляд, все ок, и за исключением подозрительных пустых квадратов, IE отображает его вполне корректно (см. рис 4), но вот при закрытии explorer'a, IE падает с воплем о критической ошибке и в лог Доктора Ватсона добавляется новая запись (естественно, если он установлен just-in-time отладчиком по умолчанию).

Рисунок 4 реакция IE 5.0 на IEdie2-2 – падение при закрытии

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

<OBJECT></OBJECT><X>Bork</X>

<OBJECT></OBJECT><X>Bork</X>

<OBJECT></OBJECT><X>Bork</X>

...


...

...

<STYLE></STYLE>

<OBJECT>

Bork

<STYLE></STYLE>

<OBJECT>

Bork

<STYLE></STYLE>

<OBJECT>

Bork

...

...

...

Листинг 2 исходный код exploit'a IEdie2-2.html

Сначала идет множество корректно закрытых OBJECT'ов с неизвестным IE 5.0 тегом <X> — источником тех пустых квадратов, — а вот дальше повторяется код предыдущего exploit'а. Но во втором случае IE падает, а в первом нет. Почему? Может уровня вложенности оказалось недостаточно для падения? Открываем iedie2-1.html в FAR'е по <F4> и увеличиваем количество OBJECT'ов вдвое-втрое. Загружаем его в IE и... опля! Ловим исключение при закрытии приложения! Это уже ближе к телу! Надеюсь, мысль ясна?

Третий exploit (http://lcamtuf.coredump.cx/iedie2-3.html) вгоняет IE в глубокую задумчивость, заканчивающуюся возбуждением исключения с автоматическим завершением его работы в аварийном режиме (см. рис. 5). Вот оно — переполнение!



Рисунок 5 реакция IE 5.0 на IEdie2-2 — падение в процессе отображения текста

Смотрим на код:

<OBJECT></OBJECT><X>Bork</X>

<OBJECT></OBJECT><X>Bork</X>

<OBJECT></OBJECT><X>Bork</X>

<OBJECT></OBJECT><X>Bork</X>

<STYLE></STYLE>

...

...

...

<OBJECT  type=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA>

Bork

<STYLE></STYLE>

<OBJECT 

type=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA>

Bork

Листинг 3 исходный код exploit'a IEdie2-3.html

Какой к черту "<OBJECT></OBJECT><X>Bork</X>"?! Ведь мы же выяснили, что IE обрабатывает его вполне корректно. Открываем файл по <F4> и отрезаем весь текст вплоть до строки "<STYLE></STYLE>" на хрен! Загружаем exploit в IE и… вновь та же задумчивость, заканчивающаяся исключением.Значит, "<OBJECT></OBJECT><X>Bork</X>" тут совсем ни при чем и реальное переполнение происходит в "<OBJECT type=AAA...AAA>", в направлении которого и надо копать.

Четвертый exploit (http://lcamtuf.coredump.cx/iedie2-4.html) во всем повторяет третий, только длина строк "AAA" слегка другая, тем не менее исключение все равно возникает, значит, переполнение имеет место быть. Остается выяснить: где именно оно происходит и как передать shell-коду бразды правления.


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