Filter vs. Hook: Что выбрать? Анализируем За и Против.
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 15.08.06 22:49
Оценка: 47 (9)
#Имя: FAQ.asm.Filter vs. Hook
Приветствую всех

в очередной раз замечена попытка
Автор:
Дата: 15.08.06
понять почему плохо "патчить ядро на каждый чих" (с) мой
Автор: Valery A. Boronin
Дата: 03.07.06
, а фильтр это хорошо

попробую наконец максимально доходчиво разобраться с этим одним из самых популярных вопросов, одним из первых кандидатов в FAQ этого форума. этот же вопрос вероятно муссируется постоянно на других форумах, в т.ч. OSR со дня их появления, так что владеющие английским, думаю, легко могут найти все о чем я поведаю там, немного порывшись.

не претендуя на полноту, попробую лишь обозначить проблемы, которые появляются при использовании разного рода хуков. ну и не забыть о преймуществах — все кто уже большие, должны знать что в таких вещах не бывает одно всегда и во всем лучше другого ведь иначе бы этого другого никому не было нужно, ясен пень.

впрочем не буду отвлекаться и сразу предлагаю использовать эту ветку форума для того чтобы дополнить то, о чем забуду упомянуть
но пожалуйста следите за объемом цитирования — модератор
ибо на эту тему можно написать и трактат и кандидатскую даже не уходя из Windows NT области (остальные популярные ОС впрочем тут как правило не лучше)

итак, тезисно, Pro et Contra или benefits vs. drawbacks, то что сразу вспоминается:

Contra или чем чреваты хуки

1. Хуки невыгружаемы. Точка.


Выгрузка хука это почти всегда катастрофа. Если кто-то выше повесил хук на наш, то после выгрузки нашего драйвера при первом же вызове, когда хук выше позовет предыдущий обработчик, т.е. нас, а мы уже ушли — результат будет известно какой: можете попытаться угадать, но я бы даже не стал этого делать ибо правильный ответ — непредсказуемый.

2. Хуки и недокументированность

Часто вызовы которые патчатся — недокументированы (например при использовании system call table hooking), а это значит, что последствия могут быть самыми разными — начнется путешествие по недокументированным и изменяющимся без уведомления "минным полям" т.к. производитель волен делать (и делает!) что угодно с приватными интерфейсами. Если хук таблицы системных вызовов делается, надо для начала четко определить правильный индекс — а они, бывает, меняются! Если речь не идет о какой-нибудь "хорошей" ф-ии выставленной ядром наружу официально. Короче, начало может быть весьма нелегким, если Вы не сам себе тестер на однопроцессорной машине с одной и той же конфигурацией ОС что подозреваю имеет место в данном случае, но могу и ошибаться
Автор:
Дата: 15.08.06


3. Хуки не всегда спасают

к примеру, сложно будет с хуком вместо файлового фильтра отследить I/O for mapped memory files

4. Несколько хуков неизбежно приведут к interoperability issues. ибо не имеют механизма синхронизации.

Это очень серьезная беда, если есть два или больше драйверов которые используют хуки, имеем классический сценарий:
— первый системный вызов: вызов хука 1 потом хука 2 и потом настоящей ф-ии
— второй системный вызов: вызов хука 2 потом хука 1 и потом настоящей ф-ии
в зависимости от того что делают хуки последствия могут быть самыми печальными. Потом еще и МС будут ругать все вместе И это хорошо еще если авторы обоих хуков достаточно умны и хотя бы используют interlocked ф-ии при установке хуков

5. Палки в колеса! Новые! От производителя! "Налетай, торопись, покупай живопись"

начиная с XP соотв. части ядра потихоньку делают защищенными от модификаций (хуков). на ХР защита довольно легко обходится простыми манипуляциями с маппингом с доступом на запись да и PTE таблицы известно где находятся, но сам факт должен насторожить — всякие новые версии ОС оснащаются разными там patch guards и т.п. — тенденция однако! А ведь тут еще скрытая появляется проблема описанная в пред пункте, что хуже. Ну и уже упомянутые фишки в свете windows updates и просто новых СП и версий ОС: индексы недокументированных вызовов съезжают или API вообще пропадает\заменяется на другой — в общем весело, спать спокойно будет нелегко.

6. Банальные косяки и криворукость

проблемы с кривыми и корявыми по исполнению драйверами, использующими разные техники для постановки хуков: вот в XP SP2 пролог ф-ий был изменен (привет пред. пункту) и кое-кто не выдержал такой подставы — вероятно, использовали жестко зашитые прологи ф-ий

Справедливости ради, в фильтре тоже легко можно накосячить как надо.

7. Безопасность

как правило жестко попирается, когда любители навесных защит на все подряд прикручивают свою security на хуках взамен Windows NT native security model. Часто даже с целью лишь ослабить\отключить встроенную защиту ибо мешает Вместо защиты образуется одна большая дыра которую уже ничем не закрыть. Конечно, я говорю о крайних случаях, просто этим пунктом хотел обратить внимание что безопасность вообще говоря идет рука об руку с хуками (см тоже пункт 7 ниже), но это бывает требует весьма тонкой работы...

предлагаю желающим продолжить список, продолжая нумерацию

Pro или аргументы за хуки

1. Экспериментальный софт


быстро въехать в фильтры для новичков может не получиться, раньше написание файлового фильтра требовало многих месяцев просто чтобы сделать то, что делается грубо говоря в 10 строк на хуке. Т.е. быстро что-то проверить на хуках — бывает разумно...

2. Маркетинг

...а иногда создать целый прототип или даже продукт! Но не будем забывать, что "быстро дешево и сердито" — это зло идет от НИХ. От пользователей конечно! ибо маркетоиды идут у рынка на поводу и часто готовы продать хоть что на соплях дабы занять рынок, а там "день простоять и ночь продержаться" в ожидании выпуска "правильного" решения (случается правильное решение начинает бесконечно откладываться ибо "и так продается", а с нами мол падают все — есть на кого свалить короче, начиная с МС, вестимо)

3. Больше информации о контексте.

Фильтр видит что файл открывается или читается через paging I/O. Хук же может на самом деле сказать что файл был открыт с execute доступом и теперь используется для создания section object (конечно если execution разрешен) и мапится в PAGE_EXECUTE память.

4. Хуки быстрее

есть и такой момент, хотя в некоторых ситуациях люди говорят ровно наоборот (если хуки плохо или криво написаны — производительность всей ОС пострадает, а с фильтрами это может быть не так заметно).

5. Сбор статистики или мониторинг чего-либо

Да хоть бы DbgMon вспомнить можно — без хука тут никак.

6. Нет другого (официального) выхода

без комментариев. на самом деле этот пункт равно как и пред. здесь чтобы сделать боевую ничью 7-7 дабы попытаться сохранить объективность

7. Безопасность
седьмым пунктом традиционно идет как ни странно опять безопасность: в кач-ве иллюстрации пункта о маркетинге приведу пример: Если особые заказчики (например те же вояки, кто не понял) требуют безопасности по цене использования недокументированных возможностей и разных грязных и не очень хаков вместо отсутствия им нужной безопасности вообще, то все догадались, что будет выбрано. Но см. то что сказано про безопасность в Contra.

предлагаю желающим продолжить список, продолжая нумерацию

резюмируя, в долгосрочной перспективе все равно лично мне кажется более разумным делать сразу все правильно, если речь идет о серьезном софте на продажу, а не об экспериментах и прототипах для демонстрации чего-либо заказчику.

Короче говоря, никому не рекомендую даже думать о хуках в production коде, если есть официальные пути. То, что многие просто не в курсе, что есть такие пути и по привычке пользуют старую добрую парадигму хуков по делу и без, то бишь "патчат ядро на каждый чих" (с) — не освобождает их от ответственности

Но если официальные средства исчерпаны, то без сомнения тут all bets are off!
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.