Техника сетевых атак
Шрифт:
Приведенный выше пример скорее гипотетический (хотя и имеет место в реальной жизни), но он наглядно демонстрирует абсурдность попытки перенесения абстрактных теоретических выкладок в действующую модель. Всегда существует угроза проникновения в систему, насколько бы она защищенной не выглядела.
Взять, к примеру, процесс отладки [114] (debug) приложений. Наличие такого механизма многократно облегчает поиск ошибок в программе, но вместе с тем позволяет изучать и контролировать ее работу. Поэтому, необходимо должным образом позаботиться о безопасности, включив в код ядра множество проверок. Существующая в UNIX схема отладки достаточно защищена, но крайне неудобна для разработчиков, поэтому не так редко приходится слышать о преднамеренной модификации ядра и переписывании системной функции ptrace, заведующей отладкой.
Традиционно в UNIX отлаживать процесс можно только с его собственного согласия. Для этого он должен вызвать функцию ptrace, разрешая ядру трассировку. Но на самом деле это ограничение эфемерно - системный вызов exec в UNIX не создает новый процесс (как это происходит, например, в Windows), а замешает текущий. Последовательные вызовы ptrace и exec позволили бы получить доступ к адресному пространству любой задачи и произвольным образом вмешиваться в ее работу, если бы не дополнительные проверки…
В UNIX вообще запрещено отлаживать setuid-программы (бедные, бедные разработчики!), иначе было бы возможно запустить, скажем, ту же программу login и, нейтрализовав защитный механизм, войти в систему с привилегиями root. Но, ведь любой процесс может исполняться не только в режиме пользователя, но и ядра! Возможность же отладки ядра позволила бы с легкостью проникнуть в систему, поэтому оказалась «заботливо» блокирована создателями UNIX. Словом, разработчики ради достижения безопасности пошли вразрез с интересами программистов!
Точно так невозможно отлаживать уже запущенные процессы. Это вызывает большое недовольство разработчиков, вынужденных удалять процесс и перезапускать его вновь (в Windows, кстати, с этим справляется на раз).
Итак, ядро перед отладкой должно позаботиться о следующих проверках: подтвердить у отладчика наличие потомка с указанным идентификатором (pid), затем убедиться находится ли отлаживаемый процесс в состоянии трассировки, не является ли эта задача stupid-программой - и только после этого приступить к отладке.
Возникает вопрос, - что такое идентификатор процесса, где он хранится и можно его подделать? В начале этой главы уже отмечалось, - состояние процесса сохраняется в его контексте, расположенном в доступном для процесса адресном пространстве и посему не защищенным от модификации. Поэтому, критические к изменению атрибуты (например, привилегии) должны быть вынесены за пределы досягаемости процесса. В UNIX для этой цели используется ядро, в котором содержится структура, именуемая таблицей процессов. Каждая запись ассоциирована с одним процессом и среди прочей информации содержит «магическое» число, называемое идентификатором процесса. Магическое - потому что интерпретировать его не может никто, кроме ядра. Идентификатор в зависимости от реализации может представлять собой индекс записи или одно из ее полей - прикладные приложения не имеют об этом никакого представления. Все что они могут - запомнить возращенное функцией fork значение и передавать его остальным системным функциям в качестве аргумента, которое ядро интерпретирует самостоятельно.
При условии отсутствия ошибок реализации (ох, уж эти ошибки!) такая схема обеспечивает надежную защиту критической информации. Но нестабильное ядро (а много ли существует стабильных ядер?) потенциально способно позволить прикладным приложениям модифицировать системные структуры. Последствия - очевидны.
Точно так, процесс можно отлаживать и без его согласия - достаточно вспомнить о срыве стека. Это позволит от имени процесса выполнить ptrace, и… правда, если ошибки программы приводят к возможности срыва стека и выполнению любого кода, вряд ли это приложение кому-нибудь взбредет в голову отлаживать.
Таким образом, атаки на UNIX это не миф, а реальность. Конечно, большинство ошибок уже найдены и исправлены, но рост сложности кода неизбежно связан с внесением новых. А, значит, администраторы никогда не избавятся от головной боли. Впрочем, с ростом количества строк в исходных текстах обнаруживать ошибки становиться все сложнее и сложнее как злоумышленникам, так и самим разработчикам.
"Мусульмане и христиане хоронят своих мертвых в земле в гробах, чтобы их защитить. Это плохо, это просто глупость, потому что, если мы не можем защитить жизнь, так как же мы сможем защитить смерть? Мы не можем защитить ничего, ничего нельзя защитить.
Жизнь уязвима, а вы пытаетесь сделать неуязвимой даже смерть. Хотите сохранить, спасти."
Чжуан Цзы
Windows NT
O В этой главе:
O История возникновения и эволюции Windows
O Атака на Windows NT
O Атаки на Windows 95 (Windows 98)
Введение в Microsoft
Вы полюбите Microsoft. Со временем… А.В. Коберниченко “Недокументированные возможности Windows NT”
Писать о компании Microsoft оказалась на удивление трудно. С одной стороны Microsoft - несомненный лидер компьютерной индустрии и культуры, программные продукты которого практически монополизировали рынок. С другой стороны, качество этих самых программных продуктов оставляет желать лучшего, а рост требований к системе вынуждает потребителей включаться в непрерывную гонку апгрейда - докупая все новые и новые мегабайты с мегагерцами. А компьютер… работает с той же скоростью, что и десять лет назад. Ну, разве не обидно?
Поговаривают о сговоре Intel и Microsoft - якобы последняя специально включает циклы задержки в свои продукты, насильно приобщая пользователей к миру быстрых процессоров. Возможно, читатель удивится, но Microsoft приложила титанические усилия в оптимизации кода Windows 95. В середине девяностых годов большинство персональных компьютеров оснащались всего четырьмя мегабайтами оперативной памяти, и руководство компании загнало разработчиков в жесткие рамки, провозгласив девиз «Четыре мегабайта или до свидания». Но при всем желании и таланте этой команды (а над Windows работали очень неглупые люди) втиснуть весь код в 4 мегабайта оказалось физически невозможно. Пришлось идти на многочисленные компромиссы и ухищрения. Если бы руководство было бы не пальцем делано и выделило команде хотя бы 8 мегабайт, Windows 95 оказалось бы совсем иной - намного более устойчивой и функциональной. Но нужно различать политику компании с талантом создателей программных продуктов.