Бесплатное повышение уровня безопасности приложений, такое бесплатное

Недавно наткнутлся на статью про EMET(Enhanced Mitigation Experience Toolkit). Тулза, которая повышает безопасность небезопасных приложений. Статья меня впечатлила и мне стало интересно как реализована вся эта система.

Для начала о том, каким образом оно улучшает работу приложения. EMET регистрирует свои DLL в Application Compatibility Interface aka shim, что позволяет грузить эти dll в процесс на этапе обработки импорта. Дальше, когда DLL подгружена в процесс, она смотрит какие настройки нужно применить для процесса в котором она загрузилась. Настройки лежат в реестре.

Итак технологии.
DEP
Если у приложения отключен DEP, EMET может его софтварно включить. Через SetProcessDEPPolicy(). То есть малварь при желании тоже может вызвать SetProcessDEPPolicy, и вернуть все как было.

ASLR
Во-первых эта фича работает только начиная с висты, что уже наводит на мысли. Во-вторых ASLR возможен только для образов с флагом IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE в OptionalHeader.DllCharacteristics. То есть форсить особенно не выйдет изначально. Что тогда оно делает? Оно смотрит какие модули в процессе имеют IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE. Размапливает такие модули (NtUnmapViewOfSection), выделяет блок памяти на котором раньше находился модуль, и снова мапит. То есть старый адрес уже занят, и системе приходится ремапить модуль на другие адреса.

SEHOP
Здесь ничего особенного, дописывают всем потокам, которые запущенны на момент срабатывания EMET, свое исключение в Teb.ExceptionList. Так что бы при раскрутке исключения проверить осталось ли оно на месте, или нет. Для того, чтобы сделать проверку вешают свой VEH обработчик. Все хорошо, только новые потоки не контролируются. А на момент срабатывания EMET, создан только главный поток.

EAF
По описанию, создается впечатление, что оно каким-то образом отслеживает попытки доступа к элементам EAT. Но на самом деле все проще. EMET берет указатель на поле IMAGE_DATA_DIRECTORY.VirtualAddress у kernel32.dll и у ntdll.dll и ставит на эти адреса хардварный брейкпоинт (т.е. через отладочные регистры). А чтобы ловить исключения он еще ставит свой VEH обработчик, где собственно принимает решение убивать или не надо. Кроме того, для того чтобы его брейкпоинты не сняли, он с перодичностью 100 мс, переустанавливает брейкпоинты. Вот так чудо защита… Шелкоду нужно очистить отладочные регистры, а потом просто уложиться в 100 мс

HSA
Защита от Heap Spraying. Метод состоит в том, чтобы забить под себя стандартные адреса куда выпрыгивает эксплоит. То есть те блоки, где при Heap Spraying будет лежать шелкод, уже будут заняты, и шелкод выполняться не сможет. Для этого имеется список таких адресов:
0x0a040a04
0x0a0a0a0a
0x0b0b0b0b
0x0c0c0c0c
0x0d0d0d0d
0x0e0e0e0e
0x04040404
0x05050505
0x06060606
0x07070707
0x08080808
0x09090909
0x14141414
Обход со стороны малвареписателей простой: использовать другие адреса .

NPA
Защита от попытки выделить память по адресу 1, т.е. нулевая страница. Защита сводится к тому, что EMET сам вызывает NtAllocateVirtualMemory по этому адресу. Снова метод “первонаха”. Ничто не мешает освободить эту память и выделить под себя снова.

BUR

Суть проста – к базовым адресам выделяемых сегментов (кучи, стека, и прочих) прибавляется случайное число размером в 8 бит

Это неправда. Они просто выделяют рандомное количество(от 0 до 255, отсюда и бред про 8 бит) блоков памяти размером 0×10000 для того, чтобы heap имел псевдорандомный адрес. Опять же, за счет того, что стандартные адреса уже заняты, heap выделят в другом месте. Но он все равно будет выравнен под размер страницы.

Вывод
Нефиговые такие memory leak’и делает этот EMET. А чего вы хотели за такие деньги? Бесплатная халтура.