Мы уже неоднократно упоминали ASLR, по справедливому замечанию MS, эта технология позволяет сделать разработку эксплойтов гораздо более дорогостоящим мероприятием, поскольку кроме эксплуатации самой уязвимости в ПО злоумышленнику нужно опереться на те или иные предсказуемые адреса в памяти в момент эксплуатации, которых ASLR его лишает. Как мы видим, в последнее время, в том числе, и с выпуском новейших Windows 8/8.1 MS решили более серьезно подойти к развертыванию данной особенности в системе. Если в узком смысле ASLR понимается как просто перемещение образа по непредсказуемым адресам с каждой перезагрузкой, то в более общем смысле эта возможность на уровне системы должна лишить атакующих любой возможности зацепится за те или иные адреса функций системных библиотек и иных системных объектов (ASLR bypass mitigation / Address Space Information Disclosure Hardening) в тех нескольких десятках байт шелл-кода, который может быть исполнен минуя DEP (ROP).
Мы не будем касаться истории ASLR, которая известна уже почти всем, отметим лишь некоторые не совсем очевидные возможности, которые Microsoft использует для улучшения ASLR в своих флагманских ОС Windows 7-8-8.1.
Microsoft использует по отношению к ASLR схожий c DEP подход, т. е. разрешать его использование по мере необходимости, если приложение скомпилировано с поддержкой. Такая практика применяется в виду очевидных проблем совместимости, которые могут возникнуть при работе программ с технологиями, на которые они могут реагировать неадекватно. Но в случае с ASLR эта ситуация работает с б о льшими ограничениями. Например, на современных выпусках Windows 8/8.1 DEP включен всегда для приложений вне зависимости от того, скомпилированы они с его поддержкой или нет (по крайней мере на 64-битном процессоре и вне зависимости от разрядности ОС и параметра загрузчика). С ASLR ситуация иная, даже работая на Windows 8/8.1 он опирается на правила его поддержки самим приложением и не включает рандомизацию образа, если в заголовке нет этого флага.
Атакующие могут использовать "преимущества" системной библиотеки, которая не скомпилирована с поддержкой ASLR, для своих целей, например, для реализации стабильной цепочки ROP, которая будет работать во всех поддерживаемых ОС. Как показывает практика последних лет, такая возможность использовалась не один раз при организации таргетированных атак. Ниже указаны такие эксплуатируемые in-the-wild уязвимости типа RCE (drive-by download).
Как видно, библиотека MS Office (hxds.dll) не поддерживает ASLR (Office 2007-2010) и атакующие смогли воспользоваться ее не меняющимся адресом загрузки для успешной эксплуатации уязвимости. В рамках декабрьского patch tuesday компания закрыла эту оплошность (которая называется Security Feature Bypass) с помощью MS13-106, обеспечивая пользователей Windows, которые работают с этой версией Office, должным уровнем защиты.
Одной из основных возможностей по поддержке ASLR, которую MS внесла с Windows 8, является функция принудительного ASLR (Force ASLR). Эта функция чем-то напоминает параметр OptIn политики DEP для всей системы. Теперь используя раздел реестра Image File Execution Options (IFEO) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options и параметр MitigationOptions пользователь может вручную включать ASLR для исполняемых PE файлов. Ниже в таблице приводится поведение ОС при загрузке в память исполняемого файла с ForceASLR и без него.
Подобная функция доступна и для пользователей Windows 7 при установке опционального обновления KB2639308.
Для того чтобы сделать Internet Explorer (10+) более безопасным, компания ввела поддержку функции принудительного применения ASLR (на Windows 8+ и для Windows 7 с установленным KB2639308) для всех библиотек, загружаемых в адресное пространство процесса браузера (ForceASLR). Таким образом, если какая-то из библиотек или плагинов изначально скомпилирована без поддержки этой функции, она будет применена к ней в принудительном порядке.
Атакующие используют преимущества Windows, которая применяет некоторую оптимизацию при работе с виртуальной памятью через последовательное выделение смежных регионов нужного размера для клиентов (процессов) через VirtualAlloc . Приложение может запросить способ выделения блока виртуальной памяти как снизу-вверх (по умолчанию), сверху-вниз (MEM_TOP_DOWN) или по фиксированному адресу (указанный функции адрес). По умолчанию Windows использует метод выделения снизу-вверх, т. е. от младших адресов к старшим она будет искать блок необходимого размера для того, чтобы отдать его приложению.
Начиная с Windows 8 на выделение виртуальной памяти может воздействовать ASLR. Такая политика до Windows 8 уже применялась для выделения блоков памяти на куче, при резервировании блоков для стеков потоков, а также TEB и PEB. Последние две структуры являются очень полезными для атакующих поскольку потенциально содержат определенное количество указателей на различные системные функции, раскрывая таким образом расположение библиотек в памяти. В Windows 8 VirtualAlloc также различает опции выделения сверху-вниз и снизу-вверх, но теперь базовый адрес начала этих выделений фиксируется ASLR при каждой загрузке ОС, т. е. не может быть предсказуем. Очевидно, что в адресном пространстве невозможно выделять память совсем хаотично ввиду быстрой фрагментации, поэтому через ASLR фиксируется именно базовый адрес начала выделения блоков для процессов. Согласно MS для процесса такая опция включается только в случае соответствующей поддержки ASLR его исполняемым файлом (/DYNAMICBASE).
High Entropy ASLR
ASLR потенциально может работать эффективнее в 64-битном адресном пространстве, поскольку там существует гораздо большая возможность по произвольному размещению памяти в таком большом адресном пространстве. Очевидно и само его использование уже является усложняющим фактором для heap spray. См. Internet Explorer EPM для Windows 7 x64. В то же время ОС до Windows 8 не используют ASLR на x64 самым полноценным образом. Главным образом это касается возможности энтропии (т. е. степени произвольности/предсказуемости выбора адреса) и сколько бит адреса будут использоваться для вычисления произвольности этого размещения. В Windows 8 такая возможность получила название High Entropy Randomization.
Windows 8+ содержит возможности, реализующие High Entropy Randomization и эта технология распространяется как на выделяемые процессом блоки виртуальной памяти, так на и загружаемые исполняемые файлы. Для 64-битных приложений, скомпонованных с флагом /LARGEADDRESSAWARE, Windows 8 выделяет для использования 8 TB виртуальной памяти (128 TB в Windows 8.1). Для сравнения, у 32-битных приложений размер пользовательской части адресного пространства ограничивается 2 GB. В таком случае возможность High Entropy Randomization позволяет применять ASLR для базового адреса отсчета выделений памяти типа снизу-вверх, используя 24 бита адреса для получения энтропии и для выделений типа сверху-вниз 17 бит адреса для энтропии. Для использования такого уровня ASLR и при использовании выделений снизу-вверх (по умолчанию) 64-битное приложение должно быть скомпилировано с флагами /HIGHENTROPYVA и /DYNAMICBASE.
Следует отметить, что сам /HIGHENTROPYVA используется как режим ограничения OptIn использования HEASLR в ОС. То есть VirtualAlloc в своем обычном поведении (выделения блоков снизу-вверх) на Windows 8 не будет использовать усиленный ASLR для приложений, которые скомпилированы без этого флага. Такое ограничение связано с вопросами совместимости и возможным непредсказуемым поведением этих приложений в данной ситуации. Как указано выше, возможность High Entropy Randomization применима и к 64-битным исполняемым файлам.
Браузер Internet Explorer 10+ использует режим High Entropy ASLR (x64). Ниже показано свойство его запущенного процесса на Windows 8. Отметим, что все системные исполняемые файлы, которые Microsoft поставляет в Windows 8, используют HEASLR.
ASLR bypass mitigations (aka Address Space Information Disclosure Hardening)
С выпуском Windows 8 компания постаралась пойти по стратегии сокрытия различных адресов системных функций и объектов. Некоторые из этих возможностей доставлялись как обновления и для Windows 7. Присутствие подобной информации по предсказуемым для атакующих адресам сильно снижает возможности существующих технологий DEP&ASLR и повышает возможность успеха атакующих к эксплуатации.
Одним из ярких примеров является обновление MS13-031, которое вводит ограничение на выделение памяти по нулевой странице (Windows 7+). Размещение кода на этой странице с последующей эксплуатацией уязвимости в драйвере используется атакующими как LPE, т. е. поднятие своих привилегий до системных и исполнение своего кода в режиме ядра. Ядро использует поле EPROCESS!LowVaAccessible для регулирования подобных ситуаций, а именно, для обнаружения минимального адреса, с которого можно резервировать регионы виртуальной памяти.
Другим примером является обновление MS13-063 для Windows Vista+ (Windows 8 по умолчанию). Это обновление убирает из UserSharedData (KUSER_SHARED_DATA) указатель на ntdll!LdrHotPatchRoutine , который использовался для быстрой загрузки необходимой атакующим библиотеки в память. UserSharedData очень полезна для атакующих, поскольку доступна по одному и тому же адресу во всех процессах, а также используется в режиме ядра.
В Windows 8.1 появилась возможность скрывать информацию об адресах объектов ядра для недоверенных приложений (чей Integrity Level < Medium). Более подробно об этой фукнции мы писали здесь. Важные функции ntoskrnl возвращают статус ошибки на запрос получения информации об адресах различных объектов ядра.
P. S. Вы можете воспользоваться бесплатным инструментом BinScope от Microsoft для проверки модулей ваших программ на поддержку ASLR (iTunes взят в качестве примера).
