Раздел: Документация
0 ... 70 71 72 73 74 75 76 ... 102 шрние своих привилегий ров!--- ,»ытый пароль никогда не передается (ну, разве что администратор не на-°ТЬ)НТ ее соответствующим образом), и используемая в ней схема аутентифи-""аиии устойчива к перехвату трафика. С дУгоП стороны, NT крайне небрежно относится к охране парольной базы от посягательств хакеров. На первый взгляд кажется, что никакой проблемы вообще нет, так как доступ к базе имеется лишь у системы, администраторов ограниченного количества специально назначенных администратором пользователей (например, операторов архива, нери одически сохраняющих базу на резервных носителях). А вот в некоторых, правда, довольно немногочисленных UNTXax, файл паролей свободно доступен всем пользователям системы и зачастую даже «видет!» по сети! Ну и что с того? — спросите вы, - ведь паролей в парольном файле все равно нет, а «обращение» хеша методом перебора занимает слишком много времени, пускай хакер перебирает, если ему это занятие так нравится... Хорошо, тогда такой вопрос: возможно ли в одиом-единствен-ном переборе взломать все машины в сети? Не спешите отвечать «нет», ибо правильный ответ: «да»! Объем жестких дисков сегодня возрос настолько, что хакер может сохранить хеши всех перебираемых паролей. Неважно, сколько это займет времени: месяц или даже несколько лет, — ведь теперь у взломщика появится возможность практически-чглювенпо восстановить пароль но его хешу — была бы только парольная база в руках! Мало того, что в NT резервные копии парольной базы но умолчанию хранится в общедоступных каталогах, так еще и атгоритм аутентификации не использует привязки (salt), в результате чего хеши одинаковых паролей в NT всегда будут совпадать, значительно упрощая тем самым взлом! Впрочем, от атак данного типа привязка все равно не спасает, разве что немного продлевает «мучения» системы. ПОВЫШЕНИЕ СВОИХ ПРИВИЛЕГИЙ Модель привилегий пользователей и механизмы контроля нрав доступа — ключевое и вместе с тем наиболее уязвимое (по статистике) звено подсистемы безопасности любой многопользовательской ОС. В общем случае к ней предъявляются следующие требования: * Модель пользователей должна быть достаточно гибкой, удобной и интуитивно понятной, в противном же случае ошибки администрирования неизбежны. 2-Механизмы контроля прав доступа должны не только гарантировать невоз-. Можность несанкционированного повышения уровня своих привилегий, но и быть максимально устойчивыми к программистским ошибкам. 3-И сама система, и работающие в ней пользователи должны обходиться минимально необходимым уровнем привилегий. Анализ показывает, что перечислен ные выше требования не выполняются ни 0Дной ОС массового назначения, а потому все они в той или иной степени ведомо уязвимы. Между тем степень защищенности UNIX и NT различна.  Модель привилегий пользователей, применяемая в большинстве UNIX, янля ется одноуровневой и допускает существование только двух типов нользовате лей: обычные пользователи и суперпользователь (он же root, или администра тор). В NT же, напротив, используется иерархическая схема, причем, помимо roota, в пей имеется еще один суперпользователь — система. Что это означает? А то, что в NT, в отличие от UNIX, каждый пользователь получает минимум необходимых ему прав и никогда не повышает уровень своих привилегии без особой необходимости. Широко распространенное заблуждение гласит, что правильное администрирование UNIX позволяет добиться такого же точно распределения прав доступа, как и в NT, пускай и ценой большего времени и усилий. На самом же деле это не так. Отсутствие системного пользователя в UNIX приводит к невозможности выполнения целого ряда действий иначе, чем временным повышением привилегий запущенной программы до roota. Взять хотя бы классическую задачу смены пароля. Пользователи могут (и должны!) периодически менять свои пароли. Но ведь в UNIX (как, впрочем, и в NT) пароли всех пользователей хранятся в одном файле, причем используемая модель привилегий не позволяет назначать различным частям файла различные права доступа. Но ведь должен пользователь как-то изменять свой пароль, верно? В UNIX эта задача решается так: утилите, ответственной за смену пароля, присваивается специальный атрибут, позволяющий ей при необходимости получать права roota, что она, собственно, и делает. Если бы этот механизм использовался только при операциях с паролями, большой беды и не было бы. На самом же деле такой атрибут необходим очень большому количеству приложений, в частности почтовым и web-серверам. Задумайтесь, что произойдет, если в одной из программ, исполняющихся с наивысшими привилегиями, обнаружится ошибка, так или иначе приводящая к возможности передачи управления хакерскому коду? А ведь такие ошибки сыплются из UNIXux программ, как из рога изобилия! Совершенно иная ситуация складывается в среде NT. Непривилегированные пользователи только в исключительных случаях вынуждены повышать свои права до уровня администратора, а все остальное время они пользуются API-функциями операционной системы, выполняющими потенциально опасные действия «руками» самой ОС. Даже если в одном из таких приложений будет допущена ошибка и хакер захватит управление, — он унаследует минимум прав и причинит системе минимум вреда. Таким образом, NT устойчива к программистским ошибкам, a UNIX чрезвычайно чувствительна к ним. УГРОЗА ПЕРЕПОЛНЕНИЯ БУФЕРА Переполнение буфера — наиболее «популярная» и в то же время наиболее коварная ошибка, которой не избежало практически ни одно сколько ни будь сложное приложение. Коротко объясним се суть: если размера выделенного программистом буфера вдруг окажется недостаточно для вмещения всех копируемых в него данных, то содержимое памяти за концом буфера окажется разрушено и чужому адресному пространству229 ynjJ—----—-- точнее — замешено) не вместившимися в буфер данными. В зависимости от уации за концом буфера могут находиться: 1 ДрУп1С °УФеРы 11 переменные программы. 1 Служебные ла,,ные — в частности, адрес возврата из функции, ч Исполняемый код. 4Незанятая страница памяти. 5Отсутствующая страница памяти. Наибольшую опасность представляют 2-й и 3-й пункты, так как они чреваты возможностью полного захвата контроля над уязвимой программой. Последний пункт менее коварен и в худшем случае приводит к возможности реализации атаки «отказа в обслуживании» (при обращении к отсутствующей странице памяти процессор выбрасывает исключение, приводящее к аварийному завершению уязвимого приложения). Угроза от первого пункта в значительной степени зависит от рода и назначения переменных, находящихся за концом переполняющегося буфера, и хотя теоретически уязвимое приложение способно на что угодно, на практике угроза оказывается не столь уж и велика. Есть еще одно обстоятельство — для полноценного захвата управления хакер должен иметь возможность исполнять на удаленной машине собственный код, обычно передаваемый непосредственно через сам переполняющийся буфер. В зависимости от расположения уязвимого буфера и «характера» операционной системы исполнение переданного хакером кода может быть как разрешено, так и пет. Все системы: и UNIX, н NT потенциально допускают существование пунктов 1,2,3 и 4, исключая лишь единственный из них — пункт 3. Следовательно, они в равной мере подвержены угрозе переполнения буфера. Кроме того, и UNIX, пМТ имеют исполняемый стек (то есть разрешают выполнение кода в стеке) и запрещают его выполнение в сегменте данных. А это значит, что переполнение буферов, содержащихся в автоматических (то есть стековых) неременных, несет в себе угрозу полного захвата управления над уязвимой программой. Правда, для некоторых UNIX существуют заплаты, отнимающие у стека право выполнения, но сфера их применения весьма ограничена (исполняемый стек необходим множеству вполне легальных программ, в частности, компиляторов). Самое забавное, что и UNIX, и NT написаны на Си — языке программирования, не поддерживающем автоматический контроль границ массива и потому подверженном ошибкам переполнения. Старожилы говорят, что в некоторых веРсиях UNIX ошибка переполнения присутствовала даже на вводе имени пользователя при регистрации в системе. Доступ к чужому адресному Пространству защитой адресных пространств процессора связано огромное количество слухов, сплетен, легенд, да и простого непонимания самой философии защиты. \ 0 ... 70 71 72 73 74 75 76 ... 102
|
