Отравляем приложения

Докучаев Дмитрий aka Forb

Спецвыпуск Xakep, номер #045, стр. 045-052-1

(forb@real.xakep.ru)

Переполнения при обработке данных

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

Смертельные картинки

Серфя инет своим любимым осликом, ты даже не подозреваешь, что тебе угрожает реальная опасность. К примеру, ты решил посетить сайт Василия Пупкина, который наколбасил довольно красивую веб-страничку. Вася предлагает просмотреть его порногаллерею абсолютно бесплатно! Понятно, что за халяву русский человек готов отдать любые деньги, и ты, конечно, щелкаешь на линк первой фотки. И вдруг осел начинает брыкаться. Ты думаешь, что это случайность, и бодро кликаешь на вторую ссылку. Твой комп начинает безбожно тормозить, а ослик перестает отвечать на запросы. После нажатия спасительной Any Key на системном блоке, ты бешено жмешь на третий линк. Как по мановению волшебной палочки начинают запускаться какие-то левые приложения, открываются непонятные окошки, а все пароли немедленно отсылаются Васе на почту. Это не мои фантазии, это – реальность. В последнее время в IE так много уязвимостей, связанных с неверной обработкой рисунков, что пора писать книги по каждому багу. Я же ограничусь статьей, в которой постараюсь донести до тебя все ужасающие последствия переполнения рисунками.

Самая первая брешь в обработке графики была найдена в конце 2002 года. Ребята из группы eEyes нашли целых две уязвимости в обработке png-изображений. Первая, по их словам, не представляла особой опасности (она связана с неверной интерпретацией заголовка), а вот вторая заставляла задуматься о собственной безопасности. Злоумышленник легко мог сформировать собственный png-файл, переполнить стек и выполнить произвольный код. Уязвимость находится в функции inflate_fast() в файле pngfilt.dll. Как известно, png (как и jpg) подвергается сжатию по специальному алгоритму deflate, в спецификации которого используется код Хаффмана. В его основе лежит сравнение специально подобранных копий образцов с символами, содержащимися в рисунке. Такая проверка происходит в вышеуказанной процедуре. Ей передается ряд параметров, два из которых говорят о промежуточном коде и его длине. В основу алгоритма заложено, что длина кода Хаффмана, равная #286 и #287, является нестабильной, а посему запрещена. Об этом знает RFC, но не знают программисты Microsoft :). Саба не в состоянии проверить запрещенную длину, поэтому параметр обрабатывается без лишней ругани. Правда, после задания подобной опции, происходят злые манипуляции со счетчиком цикла (оно и понятно, ведь запрещенная длина понимается процедурой как нулевая). В итоге, получаем циклический просмотр всего 4Gb адресного пространства с последующей перезаписью выходного буфера на 32 Кб. Финальным штрихом будет появление popup’а с сообщением об ошибочном обращении к памяти. Впрочем, eEyes утверждает, что грамотно сделанный рисунок может выполнить любой код на уязвимой системе, но насчет подобных примеров группа тактично умалчивает ;). Несмотря на то что прошло столько времени, баг до сих пор актуален. На фиктивное изображение можно натравить ослик без сервиспака до версии 6.0 включительно.