О новой архитектуре Miscrosoft .NET говорят сейчас все и превозносят ее как нечто уникальное и революционное. Не ставя под сомнение эти утверждения, хотел бы рассказать о том, насколько защищена эта архитектура и не принесет ли она специалистам новых сюрпризов. Если проследить статистику появления "дыр" в операционных системах Microsoft, то она такова:
- В 1999 году первые 15 мест по числу обнаруженных уязвимостей занимали решения компании Microsoft (исключая "счастливое" 13-е место, которое принадлежало Sun Solaris 7).
- В 2000 году в "горячей десятке" Microsoft занимала только 1-ую, 5-ую и 8-ую позиции, предоставив остальные места RedHat Linux.
- В 2001 году Microsoft переместилась с первого на седьмое место, уступив пальму первенства Linux Mandrake (другие места занимают RedHat Linux, Debian Linux, Sun Solaris и SCO OpenServer).
Проводя параллель, можно сделать вывод, что в этом году, число уязвимостей будет еще меньше. Тем более что в платформе .NET механизмы защиты реализованы на более качественном уровне. Рассмотрим их более пристально. А для начала уточним некоторые задачи, для решения которых создавалась данная концепция:
- Создание новые операционных систем, ориентированных на различные устройства (не только компьютеры) и позволяющие пользователям работать с распределенными данными независимо от их расположения.
- Создание надежных серверов, ориентированных на поддержку функционирования критичных для компании приложений, в первую очередь ориентированных на работу в Internet.
Можно выделить несколько основных компонентов Framework .NET, которые участвуют во всех механизмах обеспечения безопасности новой серверной платформы, призванной составить конкуренцию инициативе Java 2 Platform компании Sun. Common Language Runtime (CLR) - инструмент, позволяющий выполнять исполняемые модули не на "родном" языке (для данной архитектуры компьютера), а на промежуточном байт-коде, т.н. Microsoft Intermediate Language (MSIL). Знатоки Java узнают в таком подходе аналогию с байт-кодом Java, который должен выполняться на любом Java-совместимом компьютере. Т.е. программы, написанные на любом языке высокого уровня, например, C, Pascal и т.д., транслируются в MSIL, который и выполняется в среде CLR. В свою очередь механизм Common Language Runtime компилирует MSIL в машинный код либо на лету (Just-In-Time) либо с помощью CLR Native Image Generator. Но при этом осуществляется не обычная компиляция в машинный код, а с учетом некоторых внешних условий - в т.ч. и условий безопасности. Например, один из MSIL-модулей может ограничить разрешенные действия в вызываемом им подчиненном MSIL-модуле. Например, .NET-программа может разрешить только чтение локальных файлов внешним приложениям, в то время как для локальных приложений предоставить полный доступ. Можно видеть, что данная схема очень похоже на броузеры, являющиеся промежуточным звеном, выполняющим апплеты и иной мобильный код (ActiveX и т.д.) с учетом определенных прав доступа. Такой контроль всех действий MSIL-модулей даже получил свое название "управляемого кода" (managed code). Тем самым Microsoft обещает как можно быстрее избавиться от неуправляемого кода (в обход CLR), по вине которого и наносится основной ущерб информационным ресурсам (троянцы, вирусы, черви и т.д.). С точки зрения безопасности, CLR напоминает "песочницу" (sandbox) Java, которая призвана контролировать исполнение кода и не дать ему выполнить неожиданные или враждебные действия.
Второй основной компонент - библиотеки классов, которые могут многократно использоваться разработчиками в своих программах, не изобретая велосипед. С помощью таких классов реализованы различные защитные функции, включая разграничение полномочий, аутентификация, криптографическая защиты и т.д.
Безопасность .NET
Система безопасности .NET состоит из ряда элементов, часть из которых я и рассмотрю далее:
- Безопасность на уровне показаний (evidence-based security)
- Безопасность на уровне кода (access code security)
- Процесс верификации (verification process)
- Безопасность на уровне ролей (role-based security)
- Криптография
- Безопасность на уровне приложений (applications domain).
К основным элементам данного механизма можно отнести: политику безопасности (policy), полномочия (permissions) и показания (evidence). Политика безопасности уже давно известна всем пользователям не только ОС семейства Windows. В ней определяются, какие субъекты (пользователи, программы и т.д.) могут получить доступ к защищаемым ресурсам, исключая попытки нарушения их целостности, доступности или конфиденциальности. Политика безопасности, описываемая на XML, применяется не только к каждому пользователю, но и к каждому компьютеру корпоративной сети.
Полномочия описывают защищаемые ресурсы и связанные с ними права доступа. .NET Framework определяет большое число защищаемых ресурсов, включая системный реестр, файлы, журналы регистрации, DNS, Web-ресурсы, принтер и т.д. Показания в свою очередь определяют, откуда получен тот или иной код и сопутствующие параметры, например:
- автор кода (технология Authenticode),
- источник кода (конкретный адрес URL, зона безопасности /Internet, локальная сеть/ и т.д.).
Безопасность кода
Разработчик сам определяет все привилегии, которые нужны исполняемому коду для своей нормальной работы. Одной программе нужен только доступ на чтение, второй - доступ на модификацию, третей - полный доступ и т.д. Такие полномочия задаются в самом коде и всегда "следуют" за ним, что позволяет делать действительно мобильные и переносимые приложения. В процессе своего выполнения код не только может "запросить" права на доступ к какому-либо объекту (например, файлу), но и потребовать от вызывающей стороны (например, пользователя или другой программы) соответствующих полномочий на обращение к себе. Такой механизм позволяет создавать программы, которые могут выполняться только администратором безопасности и никем иным. Этот подход также позволяет создавать код, который, например, не сможет получить доступ к локальным файлам, даже если администратор разрешил такое действие ("разработчик превыше всего"). Проверив код с разных сторон, система безопасности .NET создает для него набор привилегий, с которыми код и выполняется в системе.
Процесс верификации
Технология CLR позволяет существенно ограничить возможности несанкционированных действий со стороны враждебного кода. В т.ч. CLR не разрешает создавать указатели на произвольный адрес в памяти, тем самым, защищая приложения от распространенных атак типа "переполнение буфера". Такая защита реализуется в процессе исполнения MSIL-модулей с помощью процесса верификации. Однако надо помнить, что существует потенциальная возможность обхода названного защитного механизма, используя неуправляемый код, напрямую обращающийся к ресурсам компьютера в обход CLR.
Ролевая безопасность и криптография
Данные механизмы известны уже давно и я не буду их подробно описывать. Отмечу только, что в .NET предусмотрены т.н. провайдеры аутентификации, которые удостоверяют, что субъект, пытающийся получить доступ к защищаемому ресурсы, именно тот, за кого он себя выдает. В настоящий момент .NET Framework поддерживает аутентификацию с помощью cookies, Passport (собственная технология Microsoft), Kerberos, сертификаты X.509, NTLM, криптографическая аутентификация и т.д.
Библиотеки классов .NET Framework реализует большое число криптографических примитивов, которые используется как встроенными приложениями, так и приложениями, разработанными внешними разработчиками. Эти примитивы используют давно известные алгоритмы:
- RSA, DSA - шифрование и ЭЦП с открытыми ключами;
- DES, TripleDES, RC2 - симметричное шифрование;
- MD5 и SHA1 - функция хеширования.
Защита приложений
Последний из рассматриваемых механизмов - защиты приложений. Обычно, каждому приложению выделяется своя изолированная от других приложений область (отдельный процесс), в рамках которой и выполняется приложение. Таким образом предотвращается непосредственное вмешательство одного приложения в работу другого. Однако на сильно загруженных серверах, такой подход является неоправданным и зачастую нереализуемым. Возможность контроля управляемого кода в рамках CLR и процесс верификации позволяют реализовать в рамках одного процесса несколько изолированных друг от друга приложений, каждый из которых обладает своими собственными полномочиями.
Заключение
Идеи, заложенные в .NET Framework, достаточно очевидны и не являются уникальными - унификация набора базовых функций (библиотеки классов) и улучшение управляемости приложений, в т.ч. и с точки зрения безопасности (CLR). Можно сказать, что концепция .NET вобрала в себя все известные технологии, используемые и в предыдущих версиях решений Microsoft, и в программных продуктах других компаний. Однако как уже бывало не раз, заявив о прекрасной идее, Microsoft пошла своим путем. Как говорится, "хотелось, как лучше, а получилось, как всегда". Любая, даже самая замечательная идея может быть дискредитирована неправильной реализацией, а Microsoft славится этим. Большой скандал произошел в Сан-Франциско 13 февраля 2002 года. В этот злосчастный день, на конференции VSLive были представлены .NET Framework и Visual Studio.NET. Однако уже на следующий день компанией Cigital, которая занимается разработкой программных средств в области управления информационными рисками, был выпущен пресс-релиз (/redir.php?url=www.cigital.com%2Fnews%2Fmscompiler.html%29%2C в котором говорится об уязвимости средств разработки Microsoft Visual C++.NET и Visual C++ версии 7. Данная уязвимость присуща одному из компонентов данных программных средств, ответственному за контроль переполнения буфера. Самое интересное, что обнаруженная уязвимость сама относилась к данному классу. Т.е. компонент Visual C++.NET оказался уязвим к проблеме, от которой он был призван защищать. Самое опасное, что данная уязвимость автоматически переносится во все приложения, написанные с помощью Visual C++.NET. Т.е. даже если программист и не сделает такую оплошность, это "исправит" Microsoft, внеся в созданную программу фрагмент, который может быть использован злоумышленниками. "Вместо того, чтобы защищать, он (уязвимый компонент - А.Л.) вообще ничего не делает", - говорится в пресс-релизе Cigital.
На этом можно было бы и ограничиться, если бы не сообщения о первом вирусе, который специально разработан для платформы .NET. В середине января этого года был обнаружен вирус W32/Donut, который, по мнению специалистов, был специально выпущен на волю с целью продемонстрировать уязвимость .NET.
В заключение хочу сказать, что "благими намерениями выстлана дорога в ад" и компания Microsoft, предложив действительно интересную и эффективную концепцию системы защиты своей новой архитектуры .NET, не смогла уделить достаточно внимания ее реализации, что в очередной раз поставило под сомнение желание компании Microsoft создавать действительно защищенные приложения. Однако упущение Microsoft дает шанс многим небольшим (по сравнению с Microsoft) компаниям, которые "живут за счет" того, что выпускают различные средства обеспечения информационной безопасности для операционных систем Microsoft. К таким компаниям можно отнести как западные, так и российские фирмы. Например, известная компания Internet Security Systems выпускает средства поиска уязвимостей в решениях Microsoft, включая операционную систему Windows XP и т.д. Система RealSecure Desktop Protector этой же компании предназначена для обнаружения атак на рабочие станции, функционирующие под управлением Windows XP. Говоря о компании Internet Security Systems, нельзя не сказать о том, что Microsoft приобрела лицензию на встраивание технологии обнаружения атак в свое решение MS ISA Server, которое является одним из основных компонентов линейки серверов .NET. Из российских компаний можно назвать НИП "Информзащита", которое славится тем, что выпускает сертифицированные в Гостехкомиссии России системы защиты для платформы Windows с 1992 года, пройдя путь от MS DOS до самых современных ОС компании Microsoft.