Методы обхода ASLR в новейших Zero-Day эксплоитах [часть первая]

ASLR (Address Space Layout Randomization) является одним из наиболее эффективных механизмов защиты в современных операционных системах. Но данный метод не является совершенным. Многие современные APT (advanced persistent threat) уже научились использовать инновационные технологии для обхода ASLR.

Рассмотрим наиболее известные методы байпаса, которые были обнаружены за последний год:

• Использование non-ASLR модулей
• Изменение BSTR длина/нулевое окончание
• Модификация объектов Array

Ниже будет подробно рассмотрена каждая из техник.

Non-ASLR модули

Этот способ является наиболее популярным и простым при эксплуатации. Два популярных non-ASLR модуля, которые используются в IE, и при этом не защищены ASLR: MSVCR71.DLL и HXDS.DLL.

MSVCR71.DLL используется JRE 1.6.x и поставляется из Microsoft Visual C Runtime Library, которая была скомпилирована без опции / DYNAMICBASE. Загрузка библиотеки происходит в пространство процесса IE и имеет постоянный адрес в следующих комбинациях ОС/браузерах:

• Windows 7 и Internet Explorer 8
• Windows 7 и Internet Explorer 9

HXDS.DLL поставляется из пакета MS Office 2010/2007, и собрана без поддержки ASLR. Впервые данный вектор был описан здесь, и в настоящее время является основным методом обхода ASLR для IE 8/9 на Windows 7. Эта библиотека загружается, когда браузер обращается по адресу начинающемуся с «ms-help://».

Данный метод использовался по крайней мере один раз в следующих эксплоитах: CVE-2013-3893, CVE2013-1347, CVE-2012-4969, CVE-2012-4792.

Недостатки

Требуется наличие в системе non-ASLR модулей, которые поставляются со старыми версиями ПО JRE 1.6 и Office 2007/2010, и загружаются лишь в IE8 и IE9. Обновление программ до последних версий делает данный вектор атаки невозможным.

Модификация BSTR

Впервые данная методика была освещена 2010 году Питером Вреуденхилом. Она применима только для конкретных типов уязвимостей связанных с возможностью перезаписи памяти: переполнение буффера, произвольная запись в память или возможность манипуляции указателями делают атаку возможной.

При записи в память нет полноценного контроля EIP. Большую часть времени эксплоит переписывает критические данные программы, такие как указатели на функции для выполнения произвольного кода. Основной целью нападающих является повреждение длины BSTR, что ведет за собой выход за начальные границы отведенной памяти. В случае удачи, мы можем определить адреса чужих библиотек и использовать их в качестве хранилища ROP. Таким образом возможно повреждение памяти и взятие под контроль EIP.
Для изменения длины BSTR может использоваться несколько уязвимостей. Например, некоторые уязвимости позволяют модифицировать память на один или два байта. В этом случае злоумышленник может изменить нуль-символ в BSTR, чтобы объединить строку со следующим объектом. При последующем доступе к модифицированному BSTR есть шансы получить информацию о базовых адресах загруженных библиотек.

CVE-2013-0640

Adobe XFA zero-day эксплоит использует эту технику, чтобы найти базовый адрес AcroForm.api, после чего строится ROP цепочка и удается обход ASLR и DEP. С помощью этой уязвимости, эксплоит может контролировать память перед вызовом функции из vftable:

Рассмотрим распределение памяти до операции DEC:
[string][null][non-null data][object]
После операции DEC память выглядит так:
[string][\xfe][non-null data][object]
Для получения дополнительной информации, обратитесь к записи блога immunityinc’s

Недостатки

Этот метод, обычно требует множественных манипуляций над памятью для раскрытия адресов, а для эксплуатации необходим тщательный анализ кучи для того, чтобы гарантировать то, что повреждена именно та часть памяти, которая отвечает за разделение строк, а не другие объекты. Поскольку Microsoft при создании IE9, использовала Nozzle для предотвращения spraying/fengshui, иногда атакующему приходится использовать техники VBArray для правильной обрабоки кучи.

Изменение объекта Array

Модификация длины массива похожа на изменение длины BSTR: они оба требуют наличия определенного класса «удобных» уязвимостей. После некоторого изменения длины, злоумышленник может добиться произвольного чтения или записи в память, или, что происходит в большинстве случаев — полный контроль над потоком программы и выполнение произвольного кода.
Вот список известных зиродеев с использованием этой техники:

CVE-2013-0634

Данный эксплоит нецелен на Adobe Flash Player, в котором происходит переполнение буффера при обработке регулярных выражений. Атакующий перезаписывает длину вектора объекта , а затем читает соседние регионы памяти для поиска базового адреса flash.ocx.
Здесь показана работа эксплоита:
Установка бесконечной аллокации памяти для новых объектов:

Освобождаем значение объкта с индексом 1:
obj[1] = null;
Выделяем новый RegExp объект, который пытается влезть в только что освобожденное место в памяти:
boom = "(?i)()()(?-i)||||||||||||||||||||||||"; var trigger = new RegExp(boom, "");

Позже, неправильное регулярное выражения перезаписывает длину вектора , увеличивая obj[2]. Благодаря поврежденному размер, злоумышленник может использовать obj[2] для чтения или записи в память в огромном регионе, чтобы найти базовый адрес flash.ocx и перезаписать vftable для выполнения полезной нагрузки.