убийство часового

КРИС КАСПЕРСКИ, АКА МЫЩЪХ

Спецвыпуск: Хакер, номер #072, стр. 072-072-1

NO-EMAIL

КАК ХАКЕРЫ ЛОМАЮТ ВЕЛИКИЙ PATCH-GUARD ОТ MS

В 64-БИТНЫХ ВЕРСИЯХ WINDOWS XP/VISTA, SERVER 2003/LONGHORN ПОЯВИЛСЯ ШИРОКО РАЗРЕКЛАМИРОВАННЫЙ МЕХАНИЗМ PATCH-GUARD, КОНТРОЛИРУЮЩИЙ ЦЕЛОСТНОСТЬ СИСТЕМЫ И ПРИЗВАННЫЙ УБЕРЕЧЬ ПОЛЬЗОВАТЕЛЕЙ ОТ ROOTKIT'ОВ И НЕКОРРЕКТНО РАБОТАЮЩИХ ПРОГРАММ, ВЛАМЫВАЮЩИХСЯ В ЯДРО, СЛОВНО СЛОН В ПОСУДНУЮ ЛАВКУ. НАСКОЛЬКО НАДЕЖНА ТАКАЯ ЗАЩИТА, И МОЖНО ЛИ ЕЕ ОБОЙТИ?

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

Фундамент Windows NT построен по гибридной схеме — монолитное ядро плюс загружаемые модули (в свойственной им терминологии называемые драйверами). NT поддерживает два типа драйверов: подключаемые на стадии загрузки операционной системы и загружаемые на лету, что создает проблемы устойчивости и безопасности.

Все драйвера работают в едином с ядром адресном пространстве на том же самом уровне привилегий, что и оно, «благодаря» чему могут свободно вмешиваться в работу ядра, модифицируя его по своему усмотрению. А ведь x86-процессоры предоставляют целых четыре кольца защиты (из которых NT использует только два), и технически ничего не стоит изолировать ядро от драйверов, запуская их в менее привилегированном кольце. Кстати говоря, в Висте наконец-то появились «драйвера», работающие на прикладном уровне и обслуживающие запросы от устройств, поставляемых драйверами нижнего уровня (например, драйвер USB-радио). Крах высокоуровневого драйвера уже не приводит к краху всей системы, однако сам по себе драйвер становится чрезвычайно уязвимым со стороны прикладных приложений, плюс взаимодействие с драйверами нижнего уровня требует частых переходов в режим ядра (с последующими возвращениями обратно), что отнюдь не способствует производительности. С передачей больших объемом данных также возникают проблемы. Если внутри ядра они могут легко передаваться по ссылке, то межуровневая передача должна осуществляться только по значению, то есть путем копирования через промежуточный буфер, многократно увеличивающий требования к системным ресурсам, особенно при работе с быстрыми устройствами.

Ну, и ради чего это все?

[проблемы гибридных ядер.]

Разработчики монолитных ядер стремятся включить в них все драйвера, которые только могут понадобиться конечному пользователю, что увеличивает их размер, но обеспечивает наивысший уровень стабильности и безопасности. По статистике, основным источником «голубых экранов смерти» является отнюдь не сама Windows, а драйвера, разработанные «пионерами» после плановой раскурки местной подзаборной. Хуже всего, что некоторые из них загружаются без ведома пользователя и не имеют никаких средств для деинсталляции. С другой стороны, монолитное ядро без возможности загрузки драйверов никому, за исключением серверов, не нужно. Серверы работают на вполне предсказуемом железе, им не нужны ни навороченные звуковые карты, ни сверхбыстрое видео.