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 для выполнения полезной нагрузки.
CVE-2013-3163
Уязвимость use-after-free существует в объекте CBlockContainerBlock, который используется в IE. Сам эксплоит похож на CVE-2013-0634, но является более сложным.
В основе лежит изменение памяти благодаря использованию инструкции OR. Рассмотрим следующий код:
or dword ptr [esi+8],20000h
Вот как это работает:
Во-первых злоумышленник использует спреинг в кучу на объект :
Теперь те объекты, которые там хранятся выровнены в стабильные адреса памяти. Например:
Первый DWORD, 0x03f0, является длиной вектора , а желтым отмечены значения соответствуют значениям в приведенном выше коде спрея.
Если атакующий установит ESI + 8 указывающий на 0x03f0, то размер после операции OR станет 0x0203f0, что значительно больше, чем в исходном размере.
Таким образом злоумышленник может изменить длину следующего объекта 0x3FFFFFF0.
Так злоумышленник может получить доступ к всему пространству памяти процесса IE. ASLR бесполезна, потому что злоумышленник может извлечь все образы DLL для kernel32/NTDLL непосредственно из памяти.
Используя ZwProtectVirtualMemory с адресом родных API злоумышленник может построить ROP цепочку, изменить атрибуты памяти и обойти DEP следующим образом:
Благодаря новой разметке атакующий может аллоцировать, например вектор <object> включив flash.Media.Sound(). Используя поврежденный вектор удаётся перезапись vftable указателем на ROP и шеллкод.
CVE-2013-1690
Уязвимость use-after-free в объекте DocumentViewerImpl используемым в Firefox позволяет пользователю записать значение 0×0001 в произвольное место в памяти, следующим образом:
В приведенном выше коде, все переменные, которые начинаются с «М» считываются из контролируемых пользователем объектов. Если пользователь может установить объект для удовлетворения второго условия «IF», тогда произойдет вызов setImageAnimationMode(), что вызовет перезапись памяти. Внутри setImageAnimationMode() код выглядит следующим образом:
В этом эксплоите злоумышленник пытается использовать ArrayBuffer, чтобы обработать кучу. В следующем коде каждый каждый элемент ArrayBuffer для var2 имеет оригинальный размер 0xff004.
После срабатывания эксплоита, злоумышленник увеличивает размер массива до 0x010ff004. Также злоумышленник может найти этот ArrayBuffer путем сравнения byteLength в JavaScript. Затем злоумышленник может читать или писать в память через повреждённый ArrayBuffer. В этом случае атакующий выбирает раскрытие базового адреса NTDLL из SharedUserData (0x7ffe0300) и вручную устанавливает жесткое смещение на ROP пэйлоад.
CVE-2013-1493
Эта уязвимость основана на целочисленном переполнении в JAVA CMM, которое позволяет совершать перезапись поля длины массива в памяти.
Во время эксплуатации длина массива фактически расширяется до 0x7fffffff, так злоумышленник может найти объект SecurityManager в памяти и выйти из песочницы. Этот метод является более эффективным, чем перезапись указателей на функции.
Техника модификации объекта Array является лучшей по сравнению с другими техниками. Пока у вас есть возможность писать в память, написание эксплоита не составляет труда.
Сводная информация
В следующей таблице приведены последние APT 0day эксплоиты и методы обхода, которые в них используются:
Заключение
Использование методов обхода ASLR в последнее время становится неотъемлемой частью 0day экплоитов. Ранее мы видели эксплоит для IE с использованием non-ASLR библиотек из состава Microsoft Office, и в последних операционных системах и браузерах от Microsoft были введены ограничения на использование non-ASLR модулей. Это ведет к тому, что злоумышленникам придётся использовать передовые технологии для обхода различных ограничений в своих эксплоитах. Но некоторые уязвимости предоставляющие доступ к памяти с использованием векторов <uint> и <object>, всё еще являются наиболее эффективными и гибкими.
Выше хорошо видно, как изменение одного байта даёт возможность записи гигабайтов, независимо от версии ОС, приложения или языка.
Многие исследователи публиковали исследования по обходу ASLR, например Dion Blazakis’s JIT спреинг и Yuyang’s LdrHotPatchRoutine technique. Но до сих пор мы не видели эксплоитов с использованием этих техник в реальном мире. Причиной может быть то, что эти методы являются основными и простыми методами борьбы с ASLR, а вендоры, как правило быстро исправляют подобное.
Не существует универсального способа исправить многие уязвимости. В будущем можно ожидать подобные, или даже более технологичные 0day эксплоиты, в которых будут принимать новые компоненты ОС и приложений.
Еще раз спасибо Dan Caselden and Yichong Lin за помощь в этом анализе.
Автор: akamajoris
