Философия и архитектура NT против UNIX с точки зрения безопасности

Безопасность компьютера во многом зависит от совершенства установленной на нем операционной системы. Максимально достижимая защищенность узла как такового никогда не превосходит степени защищенности самой ОС.

Oтнюдь не только консерваторы считают, что распространение электронно-вычислительных машин привнесло больше проблем, чем их решило. Человечество ни морально, ни этически, ни психологически оказалось не готово к открывшимся возможностям, и компьютерные технологии часто оказываются в руках людей, чьи устремления направлены лишь на разрушение. Если до появления Internet вирусная угроза в основном сводилась к проблеме «грязных рук» и беспорядочного копирования ПО, то теперь ситуация существенно изменилась, о чем свидетельствует, в частности, недавняя эпидемия Helkern.

Казалось бы, пользователю достаточно просто взять наиболее защищенную из представленных на рынке ОС. Однако как узнать, какую именно? Подобного тестирования еще никто не проводил, да и вряд ли оно вообще возможно. Доступный материал носит субъективный и поверхностный характер и опирается в своих оценках на непринципиальные недостатки конкретных реализаций ОС, большая часть которых давным-давно исправлена с появлением очередной заплаты.

К тому же очень трудно выбрать адекватные критерии защищенности — количество зафиксированных взломов ОС и обнаруженных «дыр» само по себе еще ни о чем не говорит: во-первых, точной статистики нет и не может быть в принципе (по-настоящему успешные взломы, как правило, не регистрируются и не афишируются), а во-вторых, данные такого рода отражают не защищенность, а распространенность тех или иных систем и интерес к ним со стороны хакеров (попросту говоря, моду).

Поэтому мы решили абстрагироваться от особенностей конкретных реализаций и сравнить потенциальную концептуальную уязвимость операционных систем семейств NT и UNIX. (Во избежание многословия под «NT», если только явно не оговорено обратное, здесь и далее будет подразумеваться все NT-подобные системы: сама Windows NT, Windows 2000 и Windows XP.) Что такое «потенциальная концептуальная уязвимость»? Это свойство архитектуры системы, которое при определенных обстоятельствах может привести к снижению степени ее защищенности, причем оно настолько тесно связано с системой, что без серьезного «хирургического» вмешательства в архитектуру ядра его не изменить. В частности, при прочих равных условиях менее сложная система считается более защищенной и, соответственно, наоборот.

Конечно, многое зависит от профессионализма разработчиков, качества проверки и т. д. Однако все эти обстоятельства практически не поддаются объективному учету, поэтому лучше их вообще исключить из рассмотрения, чем учитывать неправильно (тот факт, что Linux тестируют миллионы людей по всему миру, мало что меняет — ведь все дело в том, насколько профессионально проводится тестирование).

ФИЛОСОФСКИЕ КОНЦЕПЦИИ

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

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

Любой целенаправленный взлом начинается с изучения атакуемого объекта. Защитный же механизм, принцип действия которого неизвестен, может быть взломан только грубой силой. Следовательно, при прочих равных условиях прочность обороны обратно пропорциональна легкости анализа кода системы, что определяется в первую очередь доступностью исходных текстов защитного механизма!

Большинство систем UNIX поставляется вместе с исходными текстами, в то время как исходные тексты NT неизвестны, а анализ дизассемблерных листингов не только чрезвычайно трудоемок и утомителен сам по себе, но еще и требует изрядной профессиональной подготовки, которой могут похвастаться далеко не все. Добавим, что подсистема защиты NT значительно сложнее аналогичной подсистемы многих систем UNIX и весьма поверхностно документирована, чем и отпугивает многих потенциальных злоумышленников.

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

Малотиражные против многотиражных. ...с другой стороны, степень опасности «дыры» зависит не столько от ее «линейных размеров», сколько от распространенности операционной системы. Благодаря огромному количеству клонов, UNIX в этом отношении оказывается в весьма выигрышном положении (с точки зрения безопасности). К тому же постоянно переписываемые, да и просто альтернативные, ядра даже одну-единственную систему размножают до целого семейства, благодаря чему уязвимость, найденная в одной версии ядра, зачастую недействительна для всех остальных.

В результате хакер, нашедший «дыру» в UNIX, потенциально способен нанести намного меньший вред, чем если бы ошибка аналогичного характера была обнаружена в NT (в силу немногочисленности своих разновидностей каждая отдельно взятая версия NT установлена на значительно большем количестве машин, нежели UNIX). Именно поэтому NT все-таки взламывают или, во всяком случае, пытаются это сделать. Соблазн настолько велик, что хакеров не останавливают ни отсутствие исходных текстов, ни трудоемкость анализа. К тому же ядро NT не переписывается каждый день, и практически все незащищенные места, обнаруженные в NT 4.0, остаются актуальными и в Windows 2000, а то и в Windows XP. (Подробнее об этом рассказывается в книге Криса Касперски «Техника сетевых атак».)

Напротив, если некая операционная система установлена на считанных компьютерах, то вряд ли кто-нибудь станет тратить силы на взлом лишь из любви к искусству без весомого стимула для ее изучения. Мало распространенные операционные системы практически полностью остаются без внимания со стороны специалистов по информационной безопасности, вследствие чего частенько содержат большое количество тривиальных и легко обнаруживаемых ошибок. Тем не менее установка такой системы автоматически отсекает большую армию «хакеров» — тех, кто пользуется для атак чужими эксплоитами. А чтобы уберечься от действий профессионала, необходимо создать второй уровень защиты — узел с проверенной временем и тщательно испытанной специалистами операционной системой.

Кстати, неплохая идея: на передний план обороны водрузить какой-нибудь «редкоземельный» клон UNIX, а на следующий — NT. Большинство хакеров, как показывает практика, специализируются на одной операционной системе и лишь в исключительных случаях — на двух сразу.

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

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

Между тем ошибки крайне неоднородны по своей природе: одни, что называется, лежат на поверхности и обнаруживаются даже автоматизированными средствами контроля качества кода; другие же, напротив, зарыты так глубоко, что найти их можно только случайно. Фундаментальная проблема отладки заключается в том, что даже самая незначительная модификация программного кода чревата появлением каскада ошибок, причем порой они возникают в самых неожиданных местах. И потому внесение каких бы то ни было изменений в операционную систему и/или в сопутствующие ей приложения должно сопровождаться полным циклом повторного тестирования. Но ведь исчерпывающее тестирование, как уже было показано выше, провести невозможно!

Чрезмерная сложность NT вкупе с огромным количеством изменений, вносимых в код каждой новой версии, собственно и объясняет низкое качество ее тестирования. Несмотря на все усилия, предпринимаемые Microsoft, уязвимость NT заложена уже в самой политике ее развития, а потому является принципиально неустранимой, т. е. фундаментальной.

Большинство систем UNIX, напротив, довольно компактно и содержит минимум необходимых для функционирования системы компонентов (или, во всяком случае, их можно «урезать» до такого состояния). К тому же их медленное, эволюционное (а не революционное, как у NT) развитие отнюдь не способствует появлению грубых, легко обнаруживаемых ошибок, которыми так славится NT.

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

Никто не спорит — управлять сервером на расстоянии очень удобно, но давайте задумаемся, насколько это безопасно? Увы, никакое удобство не проходит даром! Что комфортно администрировать, то комфортно и атаковать!

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

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

Комплектность штатной поставки. Комплект штатной поставки подавляющего большинства UNIX включает в себя огромное количество разнообразных программ — от игрушек до компиляторов и интерпретаторов. А чем больше приложений установлено на машине, тем выше вероятность образования «дыр» в системе безопасности! Наличие компиляторов (интерпретаторов) на атакуемой машине значительно упрощает взлом, поскольку, во-первых, создает условия для переноса эксплоитов, во-вторых, позволяет автоматизировать атаку и, в-третьих, предоставляет доступ к функциям и сервисам, недоступным из командной оболочки.

Операционные системы семейства NT укомплектованы очень скромным набором утилит, а потому выглядят более защищенными. Впрочем, это непринципиальное различие: грамотный администратор непременно удалит из UNIX все лишнее.

АРХИТЕКТУРНЫЕ КОНЦЕПЦИИ

Механизмы аутентификации. Механизмы аутентификации пользователей (попросту говоря, алгоритмы проверки правильности пароля) и в UNIX, и в NT основываются на практически идентичных принципах, а именно: эталонный пароль нигде не хранится, вместо этого, используется его хэш (другими словами, контрольная сумма). После ввода пароля операционная система хэширует его в соответствии с тем или иным алгоритмом и сравнивает полученный результат с хэш-суммой эталонного пароля, хранящейся в специальной базе паролей. Такая схема (при отсутствии ошибок реализации, конечно) гарантирует, что, даже получив доступ к базе, злоумышленник все равно не сможет проникнуть в систему иначе, чем методом перебора. Впрочем, если спуститься с небес идеализированных математических концепций на грешную землю, то возникает вопрос, а стоило ли огород городить? В частности, в большинстве систем UNIX вводимый пароль открытым текстом передается по сети и, при наличии хотя бы одного уязвимого узла в цепочке передачи, может быть перехвачен. В NT же открытый пароль никогда не передается (ну, разве что по недосмотру администратора), а схема аутентификации устойчива к перехвату трафика.

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

На первый взгляд кажется, что никакой проблемы вообще нет, так как доступ к базе имеется лишь у системы, администраторов и ограниченного числа специально назначенных пользователей. В чем же опасность? Ведь паролей в файле паролей нет, а «обращение» хэша методом перебора занимает слишком много времени. Однако объем жестких дисков сегодня возрос настолько, что хакер может заранее сохранить хэши всех перебираемых паролей. И неважно, сколько времени это займет — месяц, год или больше. У взломщика появится возможность практически мгновенно восстановить пароль по его хэшу — была бы только база паролей в руках! Мало того, алгоритм аутентификации не использует привязки (salt), и хэши одинаковых паролей в NT всегда будет совпадать, тем самым взлом значительно упрощается! Впрочем, от атак данного типа привязка все равно не спасает.

Повышение уровня привилегий. Модель и механизм привилегий пользователей — наиболее уязвимое (по статистике) звено подсистемы безопасности любой многопользовательской ОС. В общем случае к ней предъявляются следующие требования:

Перечисленные выше требования не выполняются ни в одной ОС массового назначения, а потому все они в той или иной степени заведомо уязвимы. Между тем степень защищенности систем UNIX и NT различна.

Модель привилегий, применяемая в большинстве программ UNIX, является одноуровневой и допускает существование только двух типов пользователей: обычные и суперпользователь (он же root, или администратор). В NT же, напротив, используется иерархическая схема, помимо root в ней имеется еще один суперпользователь — система. В отличие от UNIX, каждый пользователь получает минимум необходимых ему прав и никогда не повышает уровень своих привилегий без особой надобности. Широко распространено заблуждение, что правильное администрирование UNIX позволяет добиться точно такого же распределения прав доступа, пускай ценой большего времени и усилий. На самом деле это не так.

Отсутствие в UNIX такого пользователя, как система, приводит к невозможности выполнения целого ряда действий иначе, чем путем временного повышения привилегий выполняющейся программы до root. Взять хотя бы классическую задачу смены пароля. Пользователи могут (и должны!) периодически менять свои пароли. В UNIX (как, впрочем, и в NT) все пароли хранятся в одном файле, причем модель привилегий не позволяет назначать различным частям файла различные права доступа. Но ведь должен пользователь как-то изменить свой пароль? В UNIX эта задача решается так: утилите, ответственной за смену пароля, присваивается специальный атрибут, позволяющий ей получать права root. Если бы описанный механизм использовался только при операциях с паролями, то большой беды в этом не было бы. На самом же деле, такой атрибут необходим очень большому количеству приложений, в частности серверам Web и электронной почты. Задумайтесь, что произойдет, если в одной из программ, исполняющихся с наивысшими привилегиями, обнаружится ошибка, в результате которой управление может тем или иным способом перехватить хакерский код? А ведь такие ошибки сыплются из программ UNIX как из рога изобилия!

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

Таким образом, NT устойчива к ошибкам программирования, а UNIX чрезвычайно чувствительна к ним.

Угроза переполнения буфера. Переполнение буфера — самая распространенная и в то же время наиболее коварная ошибка. Коротко объясним ее суть: если размер выделенного программистом буфера вдруг окажется недостаточным для вмещения всех копируемых в него данных, то не вместившиеся в буфер данные разрушат (а точнее, заменят собой) содержимое памяти за концом буфера. В зависимости от ситуации за концом буфера могут находиться:

Наибольшую опасность представляют пункты б) и в), так как они чреваты полным захватом контроля над уязвимой программой. Пункт д) менее коварен и в худшем случае приводит к реализации атаки по типу «отказ в обслуживании» (при обращении к отсутствующей странице памяти процессор выдает исключение, приводящее к аварийному завершению уязвимого приложения). Угроза от пункта а) в значительной степени зависит от рода и назначения переменных, находящихся за концом переполненного буфера.

Для полноценного захвата управления хакер должен иметь возможность исполнять на удаленной машине собственный код, обычно передаваемый непосредственно через переполнившийся буфер. В зависимости от расположения уязвимого буфера и «характера» операционной системы, исполнение переданного им кода может быть как разрешено, так и запрещено.

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

Самое печальное, что и UNIX, и NT написаны на Си — языке программирования, который не поддерживает автоматический контроль границ массива и потому подвержен ошибкам переполнения.

Доступ к чужому адресному пространству. С защитой адресного пространства процессора связано огромное количество недоразумений, да и простое непонимание самой философии защиты. Часто упускают из виду, что речь идет, в первую очередь, о предотвращении непредумышленного доступа, т. е. неполадки в одном процессе не должны влиять на остальные выполняющиеся процессы.

Полноценной защиты от предумышленного доступа в чужое адресное пространство ни в UNIX, ни в NT на самом деле не предусмотрено. Собственно, UNIX вообще не представляет никаких средств такого взаимодействия, кроме разве что разделяемых (т. е. совместно используемых) областей памяти, но это совсем не то. NT же обеспечивает весьма гибкий контроль доступа к адресному пространству процессоров, но значительно проигрывает UNIX в отношении безопасности. И вот почему:

Коротко говоря, NT предоставляет весьма вольготные условия для существования вирусов Stealth, клавиатурных «шпионов» и всех прочих нарушителей покоя системы.

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

Многообразие средств взаимодействия между процессами, поддерживаемых современными операционными системами, чрезвычайно затрудняет ответ на вопрос, в какой мере выполняются перечисленные выше требования на практике? Ограниченные объемом журнальной статьи, мы рассмотрим лишь три наиболее популярных средства межпроцессорного взаимодействия: каналы, сокеты и сообщения.

Неименованные каналы позволяют связывать лишь родственные процессы и потому полностью отвечают условию пункта а). Даже если посторонний процесс каким-либо образом ухитрится получить дескриптор неименованного канала не родственного ему процесса, то он (дескриптор) вне контекста своего процесса теряет всякий смыл, и ничего вредного с его помощью злоумышленник сделать не сможет. Если же последний проникнет в родственный процесс и попытается, скажем, завалить своего соседа потоком информационного сора, то... ничего не произойдет. Когда процесс-читатель уже не сможет «перерабатывать» посылаемые ему данные, система автоматически приостановит передачу, не давая атакуемому процессу «захлебнуться». Причем жертва вольна сама решать, как поступить: к примеру, она может просто закрыть канал.

Именованные каналы доступны всем процессам в системе, а в NT и тем процессам, которые исполняются на других узлах сети. Естественно, для открытия именованного канала необходимы соответствующие привилегии, но вот сформировать новый именованный канал можно и без таких привилегий, причем в NT нет легальных способов определения «авторства» создателя того или иного канала! Учитывая, что именованные каналы активно используются системой для передачи зашифрованных паролей и удаленного управления реестром, угроза внедрения подложных каналов уже не покажется незначительной.

Частично проблема решается установкой соответствующего пакета обновления (в частности, Service Pack 2 для Windows 2000). Однако данная заплата предотвращает появление подложного экземпляра уже существующего именованного канала. Между тем возможность создать подложный канал «с нуля» по-прежнему остается, а механизмов идентификации виновников происшедшего в Win32 API как не было, так и нет.

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

Именованные каналы имеют еще один серьезный недостаток: обработка каждого нового подключения требует какого-то количества системных ресурсов, а максимальное число создаваемых экземпляров канала обычно не ограничено. Плодя все новые и новые экземпляры, злоумышленник займет все ресурсы, и система рано или поздно остановится. Даже если максимальное количество экземпляров было заранее ограничено, результат будет тот же самый. Захватив все свободные каналы, злоумышленник нарушит нормальную работу остальных легальных процессов. Система, правда, не рухнет, но пользы от этого будет немного... Решить проблему поможет введение квот с клиентской (а не серверной!) стороны, но, во-первых, не совсем ясно, как их реализовать в сетевой среде, а, во-вторых, клиентскую защиту всегда легко обойти.

Сокеты, использующиеся в основном при межузловых взаимодействиях между процессами (хотя в UNIX они широко применяются и для локального обмена данными), катастрофически не защищены перед попыткой захвата всех свободных ресурсов, и огромное количество атак flooding — лучшее тому подтверждение. Кстати, наличие «неформатированных» (raw) сокетов в UNIX делает ее «платформой № 1» для любого мало-мальски серьезного нападения TCP/IP.

Системы семейства NT долгое время вообще не позволяли «вручную» формировать сетевые пакеты, и потому атаки, наподобие Land, Teardrop и Bonk, осуществить с их помощью было невозможно (правда, это еще не означает, что NT более устойчива!). Не данным ли обстоятельством вызвана патологическая любовь большинства хакеров к UNIX? Правда, сегодня не составляет труда найти драйвер NDIS к NT для работы с пакетами TCP/IP на низком уровне, так что репутация UNIX как основной платформы для взлома в скором будущем может пошатнуться.

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

Нашумевшая «дыра», когда код оболочки передается в строку редактирования привилегированного процесса с последующей установкой таймера для выполнения этого кода в адресном пространстве и с привилегиями атакуемого процесса, в настоящее время, по заверениям Microsoft, уже устранена. Полностью же запретить (или защитить) межпроцессорную рассылку сообщений невозможно, поскольку это один из компонентов философии оконной подсистемы Windows, и любые попытки внесения каких бы то ни было ограничений не замедлят привести к проблемам совместимости и к неработоспособности большого количества прикладных программ.

Оконная подсистема UNIX хороша тем, что не является неотъемлемой частью системы, при желании от нее можно отказаться, ограничившись надежным и безопасным текстовым режимом. Обмен сообщениями в графических оболочках UNIX обычно осуществляется по протоколам TCP/IP, окна и элементы управления одного процесса оказываются защищенными от посягательств всех остальных (если, конечно, сам процесс-владелец этого не захочет).

Итак, межпроцессорный обмен и в UNIX, и в NT реализован очень плохо и потому небезопасен. Адекватные средства защиты от рассмотренных выше атак ни в близком, ни в отдаленном будущем, по-видимому, не появятся — ведь «собака зарыта» на уровне базовых концепций и философии той и другой системы. А философию очередной заплатой не поменяешь.

СВОДНАЯ ТАБЛИЦА

Так какая же система надежнее? В идеале, конечно, следовало бы присвоить каждой характеристике свой «вес» и посчитать «очки» обеих систем. Однако «вес» — понятие субъективное, и нам ничего не стоило бы настроить измерительную шкалу так, чтобы более надежной оказалась наша любимая система. Подтасовка может происходить подсознательно, а потому в свободной таблице, приведенной выше, никакие весовые категории вообще не используются.

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

Крис Касперски — независимый эксперт в области компьютерной безопасности. С ним можно связаться по адресу: [email protected].

Характеристика	NT	UNIX
Качество и полнота документации	Документирована поверхностно	Документирована весьма обстоятельно
Доступность исходных текстов	Исходные тексты недоступны	Исходные тексты доступны
Сложность анализа	Высокая	Умеренная
Распространенность	Весьма ограниченное количество представителей NT, причем наблюдается ярко выраженная преемственность уязвимостей от одних версий системы к другим	Огромное количество разнообразных клонов, причем ошибки одной версии системы зачастую отсутствуют в остальных
Сложность кода	Код излишне сложен	Код предельно прост
Поддержка удаленного администрирования	Частичная	Полноценная
Комплектность штатной поставки	Минимум необходимых приложений	Огромное количество приложений, в том числе и непротестированных
Механизмы аутентификации	Устойчивость к перехвату паролей	Передача пароля в открытом виде
Использование привязки	Не использует	Использует
Выполнение привилегированных операций	Операции выполняются операционной системой	Операции выполняются самим приложением со временным повышением привилегий
Модель пользователей	Иерархическая	Одноуровневая
Защита от переполнения буфера	Отсутствует, причем сама ОС написана на языке, провоцирующем такие ошибки	Отсутствует, причем сама ОС написана на языке, провоцирующем такие ошибки
Возможность доступа в адресное пространство чужого процесса	Разрешена по умолчанию	Отсутствует
Возможность отладки процессов	Разрешена по умолчанию	Связана с рядом ограничений
Возможность отладки активных процессов	При наличии соответствующих привилегий	Отсутствует
Удаленный доступ к именованным каналам	Да	Нет
Создание подложных именованных каналов	Да, причем можно создать и канал, и даже подложный экземпляр уже открытого канала	Да, можно создать лишь подложный канал
Защита именованных каналов от нежелательных подключений	Отсутствует	Отсутствует
Защита сокетов от нежелательных подключений	Отсутствует	Отсутствует
Возможность эмуляции ввода в более привилегированный процесс	Имеется	Отсутствует