На днях Microsoft выпустил новую версию своей утилиты Enhanced Mitigation Experience Toolkit, адресно предназначенной для усиления защиты серверных (да и не только) ОС Microsoft. Так как утилита эта достаточно ценная и практичная, то предлагаю разобраться в том, что ж хорошего она приносит в систему.
Что внутри
Утилита не снабжена подробной документацией (в комплекте идёт ссылка на файл User’s Guide, а самого файла нет), поэтому хорошо бы знать, что она точно делает, и зачем нужны все указанные технологии. Это, в общем-то, хорошо знать всегда, но в случае утилиты, которая делает достаточно масштабные и глубокие изменения на уровне всей ОС – тем более.
Краткий перечень функций EMET будет таким:
- Data Execution Prevention (DEP)
- Address Space Layout Randomization (ASLR)
- Structured Exception Handler Overwrite Protection (SEHOP)
- Export Address Table Access Filtering (EAT или EAF)
- Heap Spray Allocation (HSA)
- Null Page Allocation (NPA)
- Bottom-Up Rand (BUR) (технология является нововведением в EMET 2.1, отличающим эту версию от EMET 2.0)
Давайте кратко разберемся, зачем это всё, что это и как это будет работать, заодно подробнее опишем нововведения.
Какие вообще задачи решает EMET и как он это делает
Основная задача EMET – это повышение “нижней планки” уровня защиты ОС, чтобы защитить ПО, написанное без учёта всех современных технологий безопасности. То есть предполагается, что новое и качественное ПО уже само по себе будет и на уровне проектирования, и на уровне компиляции (те же ключи /GS или /safeseh в Visual Studio, начиная с 2003) обладать указанными технологиями, а вот старое и менее качественное нуждается в доп.защите.
Замечу, что именно основная, а не единственная. EMET как управляет включением тех технологий защиты, которые теоретически могут быть добавлены на фазе компиляции ПО, так и включает то, что на уровне компилятора никак не настраивается.
Что такое DEP
Если очень обобщённо, то практически любое приложение, стартуя, резервирует для себя в оперативной памяти три типа страниц – программного кода, стека и т.н. “кучи” (heap). Количество их различается, но суть задач остаётся одинаковой – в страницах с программным кодом размещается сам код приложения, в стеке и куче – различные типы данных. DEP делает следующее – он помечает страницы с данными специальным флагом в одном из полей структуры PTE, чтобы в случае попытки передать туда указатель выполняемой инструкции было бы вызвано исключение STATUS_ACCESS_VIOLATION (0xC0000005) (которое можно перехватить, но Microsoft почему-то упорно называет его “необрабатываемым”). Т.е. функционал DEP адресно предназначен для ликвидации целого класса атак, которые проводятся следующим образом – нежелательный программный код копируется в область данных, а после на него каким-то образом передаётся управление. Если такое происходит – Вы видите окно с кодом 0xC0000005 и приложение закрывается. Кстати, из-за этого DEP мешает целому классу “кряков” и подобных приложений.
Примечание: Замечу заодно, что самих структур PTE в ОС будет не бесконечное, а ограниченное число. И этот максимум будет иметь зависимость, например, от использования ключа /3GB, который многие безапелляционно предлагают “всегда ставить в 32х битовых ОС”. Если Вы получаете Stop 0x0000003F NO_MORE_SYSTEM_PTES или Stop 0x000000D8 DRIVER_USED_EXCESSIVE_PTES – причиной вполне может быть установка данного ключа. Поэтому лучше переходите на 64х битовую ОС.
Примечание: Microsoft различает два вида DEP – аппаратный и программный. На самом деле программный DEP – это не DEP, а доп.проверка, которая перекликается с функционалом SEHOP, рассматриваемым далее. Вкратце “программный DEP” представляет из себя проверку перед вызовом обработчика исключения – расположен ли этот обработчик в памяти, помеченой как “не содержащая исполняемого кода” или нет. Если расположен, происходит такое же исключение STATUS_ACCESS_VIOLATION. Кстати – применяется только к программам без таблицы SafeSEH. Т.е., говоря проще, если Вы “правильно” скомпилируете программу, с ключом /safeseh, то “программный DEP” для неё работать не будет. И работать этот “костыль” будет только для программного кода, выполняющегося в userspace – для кода, выполняющегося в режиме ядра ОС, никакого “программного DEP” вообще нет. То есть если у Вас процессор без поддержки DEP, то включение “программного DEP” – это частичная защита и только приложений, а не самой ОС.
Вернёмся к DEP.
Данный функционал реализуется на уровне процессора (функция No-execute Page-protection (NX) у AMD или бит Execute Disable (XD) у Intel), а поддерживается в операционных системах Microsoft начиная с ОС Windows XP SP2, Windows Server 2003 SP1 и Microsoft Windows XP Tablet PC Edition 2005.
Примечание: Кстати, чтобы данный функционал – т.е. DEP – корректно использовался ОС, для 32х битных систем необходима поддержка и включение технологии PAE (Physical Address Extensions), а для 32х битового ПО, работающего на 64х битовойй системе – использование технологии AWE (Address Windowing Extension).
Говоря проще, список действий по включению DEP выглядит так:
- Найти процессор с поддержкой NX или XD
- Включить данную функцию в BIOS
- Если ОС x86, то:
- - Для Windows 2000/XP/2003 – добавить в
boot.iniв строке для загрузки текущего экземпляра ОС параметр/PAE - - Для Vista/2008 – добавить через BCDEdit команду
/set PAE forceenable - Включить DEP в настройках системы, выбрав один из вариантов (OptIn – разрешить для выбранного ПО, OptOut – включить для всех программ, кроме тех, кто сами отключат, AlwaysOn – включить для всех программ без исключения)
В случае с EMET 2.1 это делается через основное (и единственное) окно настройки программы.
Примечание: В x86-64 системах DEP вообще всегда работает для 64х битового кода, а видимые Вам “настройки DEP” влияют лишь на 32х битовый код, выполняемый через WOW64. Выключить DEP на таких системах для native x64 code нельзя.
Пойдём дальше.
Что такое ASLR
ASLR – это механизм, который “перемешивает” относительно случайным образом (насколько хорошо случайным – зависит от реализации в конкретной версии конкретной ОС – например, в NT 6.0 случайность выражается числом 2^8) выделяемые программе страницы памяти (да и сами модули при загрузке), что затрудняет проведение целого класса атак, использующих предсказание расположения этих страниц относительно друг друга.
Попробую пояснить на синтетическом примере. Допустим, есть некое приложение. Оно запрашивает 3 отдельных сегмента для данных – каждый по мегабайту. У этого приложения есть известная уязвимость, которая позволяет разместить выполняемый код в конце первого сегмента и начале второго. В случае без ASLR сегменты всегда будут фактически расположены в оперативной памяти как 1,2,3, и атака будет успешной, а в случае ASLR сегменты каждый раз будут менять расположение относительно друг друга (3,1,2 или 2,3,1 например) и атака не будет проведена.
По сути, ASLR является важной технологией, особенно эффективной в связке с DEP (обе они по отдельности далеко не так идеальны, как кажется), поэтому её включение можно считать строго необходимым.
Примечание: Ещё ASLR мешает целому классу атак на подмену адреса возврата (т.н. ret2libc), но это отдельная история
Технология реализована в Windows Vista (без сервиспаков), Windows Server 2008 SP1 и выше.
Примечание: И даже в айфонах с iOS 4.3 и выше
Как включить ASLR в EMET? Опять же – через основное и единственное окно настройки программы. Всё, что Вы сможете – это поставить этот параметр для всей системы в OptIn. Почему нет варианта AlwaysOn? Дело в том, что для компонентов ОС эта технология включена всегда и не отключается, а для ПО необходима поддержка данной технологии на фазе проектирования/компиляции. Иначе возникает вероятность (крайне малая, по факту) того, что программа будет некорректно работать в случае неготовности к “перетасовке” своей памяти. Но, кстати, если Вы выберете отдельное приложение, то для него возможно форсирование этой технологии – просто поставьте отметку в колонке Mandatory ASLR.
Дополнение: Да, включить ASLR в AlwaysOn можно. Для этого надо сделать следующее – закрыть EMET, зайти в ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET и выставить параметр EnableUnsafeSettings в единицу. После этого, запустив EMET, Вы получите возможность выставить ASLR в “всегда принудительно включен”. Учтите, что это серьёзное изменение – если в варианте OptIn логика формулируется как “перемешиваем сегменты у явно указанных модулей”, то теперь будет “все без исключений”. Это может привести к невозможности загрузки, т.к. ряд драйверов не сможет запуститься. В моём случае умерли драйверы для USB. Т.е. говоря проще, если уж включите, будьте готовы к загрузке в безопасном режиме и выключении параметра. Код ОС и ключевого ПО – Office 2010, Lync – сбоев не вызывает, по крайней мере проверенные мной версии.
Примечание: ASLR для компонентов ОС всегда “перемешивает” не только страницы данных, но и кода
Влияет ли ASLR на скорость? На скорость работы ПО – ничуть. На скорость загрузки – по идее, негативно, но по факту – в пределах погрешности измерений. Включайте поддержку ASLR всегда, когда есть такая возможность.
Дополнение: По сути, ситуация такова. Правильные разработчики ПО, делая то, что работает под NT6.0+, должны учитывать данные технологии и реализовывать их поддержку. Обычно это делается включением опции в компиляторе – например, в Visual Studio 2010 такое имеется – и последующим тестированием ПО. Если же ПО сделано без учёта данной технологии, то обычно это результат действий вида “Вышла новая винда – попробуем перекомпилировать под неё – во, вроде подожглось, отлично, пишем, что совместимы с новой версией винды”. Это неправильные действия. EMET будет помогать в такой ситуации тем, что можно будет взять и для выбранного софта включить “принудительный” – mandatory – ASLR. Если получится, то хорошо, если нет – увы, надо ждать, пока разработчики соизволят учесть существование с 2006 года встроенного в ОС механизма защиты.
Далее – SEHOP.
Что такое SEHOP
Технология Structured Exception Handler Overwrite Protection (SEHOP) работает достаточно просто – она проверяет цепочки обработчиков исключений на предмет нарушения их целостности злонамеренным ПО, так как изменение обработчиков исключений – достаточно распространённый метод захвата управления над системой.
SEHOP включен по умолчанию на Windows Server 2008 и Windows Server 2008 R2, а на десктопных ОС – Windows Vista и Windows 7 – выключен.
Примечание: Крайне позитивным является то, что изначально механизм SEHOP был только в Vista (т.е. появился в ядре NT 6.0), но благодаря установке EMET 2.1 Вы получите этот механизм и на XP / 2003.
Благодаря EMET Вы можете включить SEHOP на всей системе, либо на отдельных приложениях.
Кстати, можно включить SEHOP вручную. Для этого надо сделать следующие действия:
- Выбрать ветку реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\ - Создать там
DWORD32с названиемDisableExceptionChainValidation - Присвоить ему значение
0x0
Очень рекомендуется включать SEHOP, хотя это и приводит зачастую к проблемам в работе приложений (например, Skype). Поэтому включайте, но тщательно тестируя используемое ПО.
Что такое EAF
Конкретной информации по реализации EAF (Export address table Access Filtering) в Windows достаточно мало. Задачей этой технологии является адресная борьба с шеллкодами, и реализуется это (судя по документации) через фильтрацию чтения EAT у модулей kernel32.dll и ntdll.dll (используя аппаратные breakpoints), блокирование доступа инструкции в случае, если IP (который Instruction Pointer, а не то, что обычно) указывает на адрес вне текущего модуля (проверяется через Vectored Exception Handler). В принципе, такое должно блокировать большинство шеллкодов.
Т.е. работает EAF, говоря проще, следующим образом – ставит аппаратный breakpoint на доступ к EAT у указанных модулей, и когда breakpoint срабатывает, EAF проверяет – является ли код, который пытается обратиться к EAT, “правильным” или добавлен в модуль каким-то эксплойтом.
Примечание: Начиная с EMET 2.1, EAF работает и для 64х битных процессов на x86-64 системах. Раньше на x64 ОС он работал только для процессов, запускаемых в WOW64. Это, по идее, заблокирует большинство 64х битных эксплойтов, использущих данную схему доступа.
Примечание-2: Если совсем запутались, то EAT – это таблица, а EAF – отслеживание тех, кто её читает
Вы можете включить EAF для явно указанных приложений – EMET создаст для них специальные записи в реестре (они будут содержать информацию о том, что при запуске этих приложений необходимо использовать EAF). Запускать EMET каждый раз при старте системы не нужно – он лишь включает EAF для указанных приложений, а реализует логику EAF операционная система.
Примечание: Настройки EAF для конкретного приложения будут выглядеть как файл в каталогеC:\Windows\AppPatch\Custom\, имеющий в качестве имени GUID приложения, а в качестве расширения –.sdb
Включить EAF для всех приложений сразу нельзя. И через реестр нельзя, и через политику – тоже. Увы и ах.
Продолжим копаться скальпелем. На очереди HSA.
Что такое HSA
Heap Spray Allocation (HSA), пожалуй, одна из самых “древних” атак из рассматриваемых.
Логика атаки достаточно проста – заполнить максимально доступное количество памяти процесса-жертвы мелкими блоками, в которых будет, допустим, переход на исполняемый код эксплойта. Вариаций очень много – это может быть и заполненный единственным переходом файл swf-формата (который точно будет помечен DEP как исполняемый), может и что-то другое. Важно – что это будет много одинаковых блоков, а на кого удастся перенаправить выполнение – не важно, каждый приведёт к нужному результату.
EMET позволяет обнаружить начало такой атаки и предотвратить её. Включается только для выбранного приложения.
Замечу, что в силу того, что это не атака, а целый класс оных, говорить о том, что включение HSA является панацеей – мягко говоря, некорректно.
Что такое NPA
Это достаточно мистическая атака, базирующаяся на предположении, что будет реализована атака, базирующаяся на том, что зловредный код “займёт” для себя страницу с адресом 0x0. Для этого сама программа – EMET – занимает адрес 0x0. Впрок, так сказать.
Что интересно, если вызвать VirtualAlloc с параметром 0, то VirtualAlloc (что, в общем-то, логично) выделит память по адресу, который выберет сама, а не по нулевому. Для того, чтобы “застолбить” за собой такой адрес, как предполагается, применяется вызов NtAllocateVirtualMemory, у которой запрашивается адрес 0x1, при попытке выделения которого выделяется блок, начинающийся с 0x0.
На данный момент зловредов, использующих эту возможность, не обнаружено.
Включить NPA можно как и EAF – только для явно указанных приложений, а не на уровне системы. Когда эта технология включена, “нулевая” страница при запуске приложения будет занята в профилактических целях.
Что такое BUR
Bottom-Up Rand (BUR) – новая возможность версии EMET 2.1
Суть проста – к базовым адресам выделяемых сегментов (кучи, стека, и прочих) прибавляется случайное число размером в 8 бит, что (несмотря на казалось бы небольшой диапазон значений) делает ощутимо более сложной попытку доступа к “верхним” адресам этих сегментов. Скажем проще – с вероятностью 1/256 она будет неудачной и вызовет exception.
Смешное примечание: единственное найденное ПО, которое страдает от включения этой технологии – Live Messenger. При включённом BUR он падает при включении.
UPDATE: Новый Live Messenger – 15.4.3538.513 – не падает.
Включается BUR так же, как и NPA и EAF – только для явно указанных приложений, а не на уровне системы.
Как это всё включить, например?
Например, если речь о почтовом сервере – открыть EMET, выбрать пункт Configure Apps (внизу справа), нажать в появившемся окне кнопку Add, зайти в каталог %ExchangeInstallPath%\bin\ и выделить там все exe-файлы. После чего – перезапустить все сервисы MS Exchange.
Если речь о домашней машине – сделайте аналогичную операцию как минимум с internet-facing софтом – браузерами, мессенгерами, MS Office, продуктами Adobe (вот с этими практически обязательно).
И помните, это – не панацея, а достаточно серьёзных барьеров на пути различного вредоносного ПО. Тот факт, что есть прецеденты демонстрации теоретической возможности создать вредносное ПО, которое всё же “проходит” все указанные механизмы, ничуть не отменяет другой факт – что каждая из применяемых технологий эффективна в своей области применения, а все вместе они в разы снижают возможность многих атак, некоторые делая невозможными вовсе.
Где взять и почему ж такую полезную штуку не встроят в Windows Server, да и вообще – в любую ОС?
Загрузить его можно отсюда – http://www.microsoft.com/download/en/details.aspx?id=1677.
Почему не встроят – ну, на то есть несколько причин.
Во-первых, часть технологий – ASLR, DEP, SEHOP – уже интегрированы в ОС начиная с Vista (а тот же DEP – с XP). Просто EMET даёт возможность их “красиво” настроить из единой точки.
Во-вторых, множество ПО написано не со 100% совместимостью со всеми требованиями, выдвигаемыми со стороны ОС. Достаточно частой является ситуация, когда при выходе новой ОС производитель ПО (или драйверов) делает минимальное тестирование своего продукта. Вида “вроде подожглось, значит всё ОК, кому надо – в режиме совместимости пусть запускают, у нас своих дел много”. К сожалению, политика корпорации Microsoft, которая поддерживает совместимость ПО на протяжении десятилетий, имеет такой негативный эффект как наплевательское отношение ряда производителей ПО к выпуску новых версий продуктов. Поэтому, когда на новой платформе “закручиваются гайки” по уровню безопасности, это всегда делается крайне медленно и осторожно – именно из соображений совместимости. Достаточно усилить настройки по-умолчанию слишком сильно, и во всех СМИ будет синхронный крик “Microsoft специально делает новую ОС несовместимой со старым ПО, потому что хочет, чтобы покупали новое ПО”. Хотя по факту Microsoft просто заботится о безопасности пользователей и не хочет отвечать за некачественное ПО сторонних разработчиков. Ведь когда такое ПО “роняет систему в синий экран”, весь негатив идёт на производителя ОС – вот ведь какие плохие разработчики в Microsoft, у них же ОС падает. То, что это вызвано noname-драйвером китайского mp3-проигрывателя, который пытается записывать в защищённую область памяти, написано на экране, и понятно профессионалам, но в СМИ профессионалы в IT обычно такие статьи не пишут.
Поэтому выпустить EMET интегрированным в ОС, притом сразу с “максимальными” настройками – это убить множество любительского (да и не только) ПО и вызвать шквал негодования.
