[an error occurred while processing this directive]
Валерий Коржов
Журнал Сети #02/97
Как работает Java?
Как защищены Java-аплеты?
Безопасна ли Java?
Технология Java прочно завоевывает современный компьютерный мир. Ее широкие возможности по созданию распределенных вычислений не могут оставить равнодушными ни одного разработчика программного обеспечения. Однако часто бывает так, что серьезные возможности порождают не менее серьезные проблемы, связанные с обеспечением безопасности.
Создатели Java предусмотрели определенные методы защиты данных при распределенных вычислениях, но сейчас еще трудно понять, насколько правильно были спроектированы эти защитные механизмы. Прежде чем рассказывать о предусмотренных в Java средствах защиты, необходимо сказать несколько слов о самой технологии.
В основе технологии Java лежит клиент-серверная модель, а Java-программа состоит из нескольких блоков, каждый из которых выполняет определенную часть общей задачи. На стороне клиента присутствуют только те блоки, которые необходимы в данный момент. Причем наиболее часто используемые блоки хранятся в кэше на жестком диске или в оперативной памяти компьютера пользователя. Поскольку блок загружается с сервера, то и управлять такой системой можно с сервера, т. е. централизованно. Это также гарантирует, что пользователь всегда будет использовать самую последнюю версию программы.
Основной компонент этой технологии - виртуальный Java-процессор, который представляет собой среду для исполнения Java-команд, или так называемых байт-кодов. Любая Java-программа должна соответствовать спецификации виртуального Java-процессора, которая полностью определяет систему команд Java, типы данных, обрабатываемых Java-процессором, и его регистры. Кроме того, Java-процессор выполняет некоторые вспомогательные функции, например "сбора мусора", то есть освобождения неиспользуемой памяти.
Байт-коды разрабатывались так, чтобы максимально сократить среднюю длину команды. Java-процессор имеет минимум регистров, стековую архитектуру и часто использует косвенную адресацию. Поэтому большинство из команд занимает всего один байт, к которому добавляется (если необходимо) номер операнда - 0, 1, 2, 3 и так далее. Кроме того, для обработки каждого типа данных Java-процессор имеет свой набор команд. В результате средняя длина Java-команды составляет всего 1,8 байта (при длине команды классических RISC-процессоров в среднем четыре байта).
Кроме виртуального процессора, технология Java включает в себя (в качестве необязательного элемента) объектно-ориентированный язык программирования, построенный на основе языка C++, из которого убрали все лишнее и добавили новые механизмы для обеспечения безопасности и распределенных вычислений. Однако язык Java можно заменить любым другим достаточно совершенным языком программирования, добавив в него все необходимые элементы. Например, уже существует компилятор языка Ада, который генерирует программы в байт-кодах Java.
Язык Java дает программистам возможность не просто разрабатывать новые программы, но и использовать элементы уже написанных и проверенных программ. Такой модульный принцип позволяет быстро писать новые программные продукты и эффективно модернизировать старые. Кроме того, в стандарт языка входит множество полезных библиотек, на основе которых можно строить вычислительные системы любой сложности. Причем этот стандартный набор постоянно пополняется новыми важными функциями.
Еще одной особенностью Java являются аплеты. Аплет - это небольшая программка, в которой должно быть определено несколько обязательных функций. Аплет загружается по сети и может выполняться на Web-браузере, который поддерживает язык Java. Именно эта часть Java-технологии предназначена для использования во всемирной сети Internet, и поэтому защита должна распространяться как на сам аплет, так и на клиента сети, который использует этот аплет.
Наиболее уязвимыми с точки зрения безопасности компонентом Java-технологии являются аплеты, поскольку их может использовать любой клиент, который вовсе не обязан знать правила "техни-ки безопасности" при работе с этими небольшими программками. Именно поэтому для аплетов предусмотрены самые жесткие методы защиты. Хотя различные браузеры и программы просмотра аплетов могут по-разному защищать информацию пользователя от нападения, но в общем случае аплету должно быть запрещено следующее:
Эти правила обеспечивают следующие компоненты Java-технологии.
В классе SecurityManager перечислены методы, которые используются системой для контроля действий аплета в зависимости от характеристик окружающей среды. Программа, которая применяется для просмотра аплета, создает подкласс SecurityManager, который и реализует необходимую политику безопасности. Ссылка на этот SecurityManager записывается в объекте System.
Еще один механизм безопасности встроен в загрузчик аплетов и программ (ClassLoader). Браузер переопределяет этот класс и реализует свои собственные правила работы с сетевыми протоколами. Одна из основных функций загрузчика объектов - разделение пространства имен разных аплетов и операционной системы, что позволяет избежать их взаимного влияния.
Другая, не менее важная, функция загрузчика - верификация байт-кодов, т. е. проверка правильности полученного элемента Java-программы и его целостности. В процессе верификации выясняется следующее:
Целями такой проверки являются выявление неправильного использования косвенной адресации, которое может привести к нарушению в работе виртуального процессора, и проверка целостности аплета. Этот механизм обеспечивает защиту и надежную работу распределенной программы, что позволяет не загружать в браузер всю Java-программу целиком, а подгружать ее небольшими блоками по мере необходимости.
Сам виртуальный Java-процессор также имеет встроенные механизмы защиты от нападения. Например, поскольку байт-коды Java интерпретируются, то можно контролировать индексы массивов, что позволяет избежать переполнение буфера - самой распространенной и опасной ошибки. Встроенные механизмы обработки исключительных ситуаций позволяют эффективно решать возникающие конфликты, а "сборщик мусора", который очищает неиспользуемую память, не дает возможности "нападающему" просмотреть "отходы", которые могут содержать полезную информацию.
Не всегда хорошие идеи столь же хорошо воплощаются. Так случилось и с Java. Хотя защитные механизмы этой технологии очень хорошо продуманы, но их реализация еще далека от совершенства. Поэтому далее будет приведен небольшой список возможных "нападений". Не берусь судить, насколько серьезна опасность, связанная с каждым из описанных дефектов защиты, - я не хакер. Я просто хочу предупредить об этой опасности. При этом мне бы не хотелось. чтобы у читателя сложилось мнение, что Java "беззащитна". Не стоит забывать: Java все-таки имеет достаточно мощную защиту, "взломать" которую не так-то просто.
Блокировка сервиса
Это "нападение", в результате которого частично или полностью блокируется работа пользователя и даже может быть выведен из строя браузер. Вот далеко не полный список возможных вариантов такого "нападения":
"Тайные" каналы
Эти каналы позволяют "нападающему" получать информацию даже через систему защиты (брандмауэры). Существование "тайных" каналов в браузере делает его очень опасным. В качестве "тайного" канала можно использовать следующие действия аплетов:
Информация, известная аплетам
С помощью этой информации "нападающий" может получить некоторые сведения, которые впоследствии могут быть им использованы для "взлома". Эту информацию можно передавать даже через брандмауэры по тайным каналам, которые описаны выше. Аплетам обычно известна следующая системная информация:
Ошибки реализации
Это основной способ "нападения". Ошибки обычно очень трудно находить и исправлять. Причем для исследования пользовательской системы можно использовать информацию, которая доступна аплетам. Например, если "нападающий" знает, что в определенной версии Internet Explorer есть "полезная" для него ошибка, то, считывая с помощью аплета название и версию браузера и передавая эту информацию по тайным каналам (запрос по несуществующему URL), он получает информацию о своей "жертве".
Перехват ошибок
Java предусматривает перехват исключительных ситуаций. Это необходимо для составления более наглядных программ, благодаря которым обработку всех ошибок можно выполнять централизовано. Однако перехват ошибок позволяет игнорировать исключительные ситуации, создаваемые, например, SecurityManager. Такая ситуация очень опасна, так как позволяет "нападающему" заменить ClassLoader, SecurityManager и другие ключевые объекты. Естественно, хотелось бы блокировать подобные ситуации еще при загрузке аплета, но современные загрузчики этого не умеют. Вероятно, этот недостаток будет скоро исправлен.
Имя упаковки
Если "/" - первый символ имени упаковки, то система попытается загрузить эту упаковку с локального диска, причем загружается она с меньшими требованиями к безопасности, так как предполагается, что запускаемому с локального диска аплету можно доверять. Таким образом, любой Java-класс, который "атакующий" может записать на локальный диск, может быть загружен с ослабленной защитой. Причем "опасные" классы могут быть записаны на диск с помощью механизма кэширования браузера. Поэтому становится возможной загрузка "агрессивного" класса с ослабленной защитой. Вероятно, и этот недостаток загрузчиков будет скоро исправлен.
* * *
Перечисленные лазейки в системе безопасности Java не означают полной беззащитности пользователей при возможных "нападениях". Чтобы воспользоваться этими ошибками, хакерам еще предстоит изрядно попотеть. Поэтому не спешите стирать свой браузер, а просто относитесь к аплетам и Java-программам чуть более настороженно.
Установить баланс между возможностями загружаемых аплетов и защитой клиентской системы довольно сложно. Некоторые компании предлагают усилить защиту клиентской системы от "агрессивных" аплетов, не ограничивая при этом возможностей "благонадежных" программ. К сожалению, предлагаемые решения невозможно сделать независимыми от конкретной платформы, что противоречит требованию абсолютной переносимости Java-программ. Поэтому, видимо, информационная безопасность еще долгое время будет оставаться одним из сложных и спорных вопросов Java-технологии.
Валерий Коржов - сотрудник компании Jet Infosystems. С ним можно связаться по тел.: 972-11-82 или электронной почте oskar@jet.msk.su
* На основе "Ответов на часто задаваемый вопросы по безопасности WWW", которые можно найти по адресу http://beaver.fu-q.com/nomad/faqs/www/index.html.
[an error occurred while processing this directive]