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

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

Хакер, номер #091, стр. 091-060-4

Предположим, что длина строки s превышает 2 Гб, тогда как знаковый бит переменной len будет установлен в единицу, и выражение (len < MAX_LEN) окажется истинным, поскольку len – отрицательный, а всякое отрицательное число, как известно, меньше любого положительного. В то же самое время функция strncpy трактует len как беззнаковый аргумент и копирует в буфер buf очень много байт.

Чтобы избежать переполнения, необходимо явно объявить переменную len как unsigned int, но разработчики всегда об этом забывают. В том числе и разработчики Оперы.

Итак, значит, Опера. Возьмем английскую версию 8.52 и будем ее пытать (http://www.opera.com/download/index.dml?opsys=Windows&lng=en&ver=8.52&platform=Windows&local=y). Это последняя уязвимая версия, и Opera 8.54 уже исправлена. Точнее, как бы исправлена. Беглый просмотр под дизассемблером показывает, что знаковое сравнение там по-прежнему встречается, и всего лишь остается разобраться, какие именно входные параметры подвержены переполнению. Короче, надо копать от забора до обеда.

Начнем с того, что файл opera.exe упакован ASPack'ом — в hex-редакторе хорошо видны секции .aspack, .adata, а PEiDE даже определяет версию упаковщика 2.12. Однако при своем размере 78 Кб ничего интересного он содержать не может, и весь функционал сосредоточен в opera.dll c размером 2,3 Мб, который также упакован ASPack'ом.

Чтобы не искать готовый распаковщик (не все распаковщики умеют распаковать динамические библиотеки), воспользуемся утилитой PE-TOOLS и снимем дамп с opera.dll. Таблица импорта останется искаженной, но зачем она нам?! Мы же ведь не crack собрались писать, а проводить исследование на предмет безопасности. Главное, чтобы полученный дамп было можно загрузить в IDA Pro или hiew, а все остальное — уже дело техники!

Поскольку стартовый код точки входа в dll (dllentry) искажен, IDA Pro не может опознать компилятор и загрузить сигнатуры, оставляя нас без библиотечных имен, что значительно усложняет анализ. Впрочем, отождествить компилятор можно и вручную по текстовым строкам, оставленным из патриотических соображений поборников авторский прав. Просмотр дампа в hiew'е убеждает нас в том, что Опера была скомпилирована ничем иным, как Microsoft Visual C++:

.67F3DFBC: 4D 69 63 72-6F 73 6F 66-74 20 56 69-73 75 61 6C Microsoft Visual

.67F3DFCC: 20 43 2B 2B-20 52 75 6E-74 69 6D 65-20 4C 69 62 C++ Runtime Lib

.67F3DFDC: 72 61 72 79-00 00 00 00-52 75 6E 74-69 6D 65 20 rary Runtime

Здесь ведется поиск текстовых строк в opera.dll, что позволяет легко и быстро отождествить компилятор.

Остается только загрузить соответствующие сигнатуры. Это делается так: в меню File IDA Pro выбираем пункт Load file - FLIRT signature file, в появившемся списке имеющихся сигнатур находим строку «vc32rtf Microsoft VisualC 2-7/net runtime» и жмем <ENTER>. Вот теперь с файлом можно по-настоящему работать!

Как найти места потенциального знакового переполнения? Существует множество путей. Например, можно искать все команды JL, JLE или (если этих команд окажется слишком много) перебирать все вызовы строковых функций типа strlen, strcpy, wcsncpy, обращая внимание на те из них, что соседствуют со знаковым сравнением длины копируемой строки. Это уже почти переполнение! «Почти» потому что, для совершения атаки необходимо, чтобы копируемые данные были как-то связаны с пользовательским вводом, и нигде по пути не «усекались». В принципе, задачу можно автоматизировать, написав специальный скрипт, но его разработка займет довольно продолжительное время, поскольку придется учитывать слишком много ситуаций. Так что «ручная» работа все же окажется эффективнее.