Раздел: Документация
0 ... 71 72 73 74 75 76 77 ... 102 вую очередь предназначается для непредумышленного доступа, то есть \* чтобы процесс, пошедший «в разнос», не утащил бы на тот свет и всеост!ЯТого-процессы, исполняющиеся параллельно с ним.b,ll,ie Полноценной защиты от предумышленного доступа в чужое адресное im, ство ни в UNIX, ни в NT на самом деле нет. Собственно, UNIX вообще це ставляет никаких средств такого взаимодействия, кроме разве что разде™" (то есть совместно используемых) областей памяти, но это совсем не то Щ** обеспечивает весьма гибкий контроль доступа к адресному пространству цессоров, по все-таки значительно проигрывает UNIX в отношении безопасно сти. И вот почему: •в NT доступ в чужое адресное пространство но умолчанию разрешен всем даже гостю, и если какой-то процесс (точнее его владелец) не хочет, чтобы в него проникали, он должен заявить об этом явно; •в UNIX для отладки процессов необходимо, чтобы отлаживаемый процесс не только дал согласие на свою отладку, но и выполнил некоторые действия, причем отладка уже запущенных процессов запрещена! NT же беспрепятственно позволяет отлаживать активные процессы и инициировать отладку новых, естественно, с наследованием всех привидений процесса-отладчика (то есть в общем случае отладка более привилегированных процессов из менее привилегированных невозможна). Короче говоря, NT предоставляет весьма вольготные условия для существования Stealth-вирусов, клавиатурных и паролей шпионов и всех прочих тварей, нарушающих покой системы. МЕЖПРОЦЕССОРНЫЕ КОММУНИКАЦИИ Процессы должны обмениваться данными, — это бесспорно, в противном случае такая система не будет никому нужна. С другой стороны, наличие каких то пи было средств межпроцессорного взаимодействия потенциально позволя ет атакующему пагубно воздействовать на чужой процесс, причиняя его вла дельцу те пли иные неприятности. Например, «напрягать» жертву носылк0-больших объемов бессмысленных данных, которые та категорически "еХе]1 принимать. Следовательно, каждый из взаимодействующих процессов DP-иметь возможность: •самостоятельно решать, с кем ему взаимодействовать, а с кем нет; •уметь определять подлинность процессов отправителей и процессов П°- чателей; •контролировать целостность передаваемых/принимаемых данных; •создавать защищенный канал связи, устойчивый к перехвату трафика- Многообразие средств межпроцессорного взаимодействия, поддержи"3 современными операционными системами, чрезвычайно затрудняет от&1 .• a выполняются ли перечисленные выше требования на практике? Здесь • рассмотрим лишь некоторые из наиболее популярных средств межпроцессного взаимодействия: каналы, сокеты и сообщения. НЕИМЕНОВАННЫЕ КАНАЛЫ НЕ нованные каналы позволяют связывать лишь родственные процессы и потому полностью отвечают условию «самостоятельно решать, с кем ему взаимодействовать, а с кем нет». Даже если посторонний процесс каким-либо образом Ухитрится получить дескриптор неименованного канала не родственного ему процесса, то он (дескриптор) вне контекста своего процесса потеряет всякий смысл, и ничего «пакостного» с ним злоумышленник сделать не сможет. Если же злоумышленник проникнет в родственный процесс и попытается, скажем, облить своего соседа толстой струей информационного мусора, то... ничего не произойдет. Если процесс-читатель не будет успевать «заглатывать» посылаемые ему данные, система автоматически приостановит процесс передачи, не давая атакуемому процессу «захлебнуться». Причем жертва вольна сама решать — выносить ли ей такие издевательства дальше или же просто закрыть канал и послать невоспитанного хакера куда подальше. ИМЕНОВАННЫЕ КАНАЛЫ Именованные каналы доступны всем процессам в системе, а в NT — и процессам, исполняющимся на остальных узлах сети. Естественно, для открытия именованного канала необходимо иметь соответствующие привилегии, но вот для создания нового именованного канала такие привилегии не обязательны, причем под NT не существует легальных способов определения «авторства» создателя того или иного канала! Учитывая, что именованные каналы активно используются системой для передачи зашифрованных паролей и удаленного управления реестром, угроза внедрения подложных каналов уже не покажется незначительной. Частично эта проблема решается установкой соответствующего пакета обновления (в частности, для Windows 2000 это Service Pack 2), который предотвращает создание подложного экземпляра уже существующего именованного канала, между тем возможность создать подложный канал *с нуля» по-прежнему остается, а механизмов идентификации создателей канала в Win32 API как не было, так до сих нор и нет. Локальность именованных каналов в UNIX оказывается одновременно и сильной, и слабой ее стороной, ем не менее отсутствие удаленного доступа к каналам еще не дает повода раскаляться — ведь создать подложный канал может даже гостевой пользователь, что в ряде случаев позволяет ему успешно атаковать более нривилегиро-"анные процессы. енованные каналы имеют еще один серьезный недостаток: обработка каж-toro нового подключения требует какого-то количества системных ресурсов, аМаксимальное количество создаваемых экземпляров канала обычно не огранено. Создавая все новые и новые экземпляры, злоумышленник «сожрет» "Се Ресурсы, и система рано или поздно «встанет». Даже если максимальное количество экземпляров было заранее ограничено, получим те же самые щ только в профиль. Захватив все свободные каналы, злоумышленник наруМ1и нормальную работу всех остальных легальных процессов. Система, правда рухнет, но пользы от этого будет немного... Решение проблемы состоит в ввел нии квоте клиентской (а не серверной!) стороны, но, во-первых, не совсем ясно как такое реализовать в сетевой среде, а, во-вторых, клиентскую защиту всегд-легко обойти. СОКЕТЫ Сокеты, использующиеся в основном в межузловых межпроцессорных взаимодействиях (хотя в UNIX они широко применяются и для локального обмена данными), так же катастрофически незащищены перед попыткой захвата всех свободных ресурсов, и огромное количество постоянно совершающихся flooding-атак — лучшее тому подтверждение. Кстати, наличие «сырых» (RAW) сокетов в UNIX делает ее платформой номер один для любой мало-мальски серьезной TCP/IP-атаки. Системы семейства NT долгое время вообще не позволяли «вручную» формировать сетевые пакеты, и потому атаки типа Land, Teardrop и Bonk осуществить с их помощью было невозможно (правда, это еще не означает, что NT устойчива к таким атакам). Не этим ли обстоятельством вызвана патологическая любовь большинства хакеров к UNIX? Правда, сегодня только ленивый не найдет NDIS-драйвер к NT, позволяющий работать с TCP/IP-иакетами на низком уровне, так что репутация UNIX как чисто ха-керской платформы в скором будущем обещает пошатнуться, тем более что Windows 2000/ХР сырые сокеты уже поддерживают. СООБЩЕНИЯ Сообщения представляют еще одни тип неавторизированного межпроцессорного взаимодействия. В NT любой процесс независимо от уровня своих привилегий может послать сообщение окну другого процесса (в том числе и более привилегированного!), причем нет никакой возможности установить отправителя сообщения! Вот тебе, бабушка, и сказка о безопасности! Находим окно какого-нибудь привилегированного приложения (а такая возможность у насесть), получаем дескриптор интересующего нас элемента управления (кнопки, пункта меню, строки редактирования) и... эмулируем ввод пользователя!!! Привилегированный процесс все сделает за нас, так ничего при этом и не заподозрив! I аким образом, запускать средства администрирования безопасно лишь на заведомо «стерильной» машине (по сети сообщения не передаются, точнее.-- не передаются в штатной конфигурации NT, но ряд утилит удаленного управления системой позволяет обмениваться сообщениям и но сети). Нашумевшая дыра, связанная с передачей shell-кода в строку редактирован»1* привилегированного процесса с последующей установкой таймера, выпоЛ,я ющегоэтот код в адресном пространстве и с привилегиями атакуемого пронеС" са, в настоящее время по заверениям Microsoft уже устранена. Подробности рецепта «лечения» еще не известны, но, но всей видимости, они своДЯтсЯ 0 ... 71 72 73 74 75 76 77 ... 102
|
