Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #86, ФЕВРАЛЬ 2006 г.

WMF: баг года

крис касперски ака мыщъх

Хакер, номер #086, стр. 086-066-4


Что же касается альтернативных браузеров, то Opera и ранние версии FireFox (1.0.4) не поддерживают отображение метафайлов, показывая пустой квадрат, щелчок по которому приводит к появлению диалогового окна, предлагающего сохранить файл на диск или открыть его с помощью ассоциированного с ним приложения.

Обычно это уязвимый Windows Picture and Fax Viewer, однако у меня он не установлен, так как я смотрю все файлы при помощи Microsoft Photo Editor'а (который не поддерживает wmf-файлов и потому неуязвим) или Irfan Viever'а (уязвим под NT, но безопасен под 9x). Агрессивный характер Google Desktop Search мы уже отмечали. Поздние версии FireFox (1.5) открывают метафайлы при помощи Windows Media Player, который их ни хрена не поддерживает и потому зловредный код не получает управления.

Но даже при «ручной» работе с GDI необходимо очень сильно постараться, чтобы выполнить код внутри wmf-файла. Возьмем exploit.wmf, прилагаемый к статье, и выбранный из wmf-checker'а от Ильфака и попробуем вывести его на экран функцией PlayMetaFile, как показано в листинге 1. Под W2K SP4 (другие системы не проверял) «честные» wmf-файлы нормально выводятся, подтверждая, что программа написана правильно, но exploit.wmf не получает управления! Shell-код не выполняется, а ведь должен… Но стоит заменить контекст окна контекстом специально созданного метафайла, как на экран выпрыгивает диалоговое окно, вызываемое shell-кодом:

DC = CreateEnhMetaFile(0, 0, 0, "demo"); // проигрываем метафайл в другой метафайл

h_meta = GetMetaFile("exploit.wmf"); PlayMetaFile(DC, h_meta);

Под Widows 98 exploit.wmf наглухо вешает систему независимо от выбранного контекста. Так же поступают и другие эксплойты, выловленные в Сети. Так что количество уязвимых платформ реально ограничивается одной лишь NT, причем версия под Intanium требует специально спроектированного shell-кода.

Вот тут некоторые задают вопрос: защищает ли DEP от атаки или нет? Чисто теоретически, аппаратный DEP предотвращает непредумышленное выполнение машинного кода в области данных, но не препятствует явному назначению нужных атрибутов функцией VirtualAlloc/VirtualProtect. Поэтому весь вопрос в том, в какой регион памяти загружает метафайл то или иное приложение.

спасет ли DEP?

Попробуем это выяснить с помощью метафайла exploit.wmf и отладчика OllyDbg. Чтобы бестолку не трассировать километры постороннего кода, давай внедрим в exploit.wmf точку останова, предварительно скопировав его в wmf-int3.wmf, чтобы не испортить оригинал. Открываем метафайл в hiew'е, давим <F5> (goto) и переходим по смещению 1Ch, откуда, собственно говоря, и начинается актуальный shell-код. Переходим в режим редактирования по <F3> и пишем CCh пока не надоест. Сохраняем изменения по <F9> и выходим.

Назад на стр. 086-066-3  Содержание  Вперед на стр. 086-066-5