Защита Java и ActiveX

Коды Java и ActiveX выполняются локально, на машинах конечных пользователей, подвергая эти машины опасности нападения. Тем важнее знать, каким образом подобные атаки можно предотвратить.

Итак, любой пользователь браузера Web - будь то Netscape Navigator или Internet Explorer корпорации Microsoft - становится рядовым растущей армии пользователей Java. При этом неважно даже, что такой пользователь может вовсе не уметь программировать и не претендует на звание разработчика ПО, знающего алгоритмические языки вдоль и поперек и способного с закрытыми глазами найти ошибку в коде C или C++. Стоит только человеку запустить один из самых популярных браузеров - и он уже пользователь Java, нравится ему это или нет.

Нет ничего проще, чем заглянуть в волшебный мир Java - каждый, кто хоть раз видел какое-нибудь переливающееся всеми цветами радуги, вращающееся название в окне браузера, может считать, что уже побывал там. Корпорация Microsoft, не желая отстать от Sun Microsystems, предложила свой собственный исполняемый код, известный как ActiveX. Эта среда позволяет разработчикам создавать элементы управления, основанные на программной архитектуре Component Object Model (COM). Последняя служит для поддержки создания приложений на таких языках, как C и C++. Апплеты Java широко применяются сейчас на узлах Web, при этом пока только немногие используют ActiveX.

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

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

Пожалуй, всякий "ходивший по Сети" хоть раз да читал сообщения о мобильных программах, делающих на настольных компьютерах всякие пакости. (Более подробно они описаны во врезке "Хороший, плохой, злой".) Правда в том, что большинство представителей прессы, равно как и разработчиков, не имеет целостной картины возможной опасности, которую несут Java и ActiveX.

В этой статье мы хотели бы дать общее представление о мобильных кодах, в том числе об их важности для каждого, кто занимается бизнесом, особенно используя для этой цели Internet. Кроме того, здесь рассмотрены модели обеспечения безопасности как для Java, так и для ActiveX. Статья также познакомит читателей с теми мерами, которые можно принять, чтобы не стать жертвой злонамеренных программ.

ОБРАТИМСЯ К JAVA

Когда в начале 1995 года Sun представила Java, разработчикам и производителям показалось, что у них в руках очутилась волшебная палочка. У них были все основания радоваться: Java обещал сделать Web реально пригодным для коммерции и давал хорошие шансы вырваться вперед и победить конкурентов. Апплеты Java - маленькие порции переносимого исполняемого кода, работающего на всех имеющих доступ к Web машинах, давали преимущество тем компаниям, которые хотели бы выйти на необъятный интерактивный рынок.

Поначалу апплеты применялись в основном для рекламы в Web. Производители заполнили узлы блистающими и крутящимися заставками для привлечения внимания досужих "путешественников". Даже в этих самых ранних апплетах код, порождавший их, передавался на клиентскую машину, где и выполнялся поддерживающим Java браузером. Уже тогда приходилось только гадать, кто же был автором этого кода, и перед пользователем стояла альтернатива: отказаться от наслаждения красотой Web или рисковать целостностью своей системы.

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

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

общее представление о том, как Java работает и как среда Java реализована

в Web. Прежде всего разработчики пишут исходный код на языке программирования Java. Компилятор преобразует этот код в байт-код Java. Байт-код в форме апплета размещается на странице Web, доступ к которой осуществляется при помощи браузера, рассчитанного на работу с Java. Браузер проверяет код, после чего виртуальная машина Java (Java Virtual Machine, JVM) осуществляет выполнение апплета на клиентской машине (см. Рисунок 1).

(1x1)

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

Вскоре после того, как Java получил широкое распространение, специалисты и рядовые пользователи стали обнаруживать пробелы в обеспечении безопасности комплекта разработчика Java Developers Kit (JDK). JDK состоит из нескольких компонентов (включая язык для преобразования команд в байт-код и JVM для выполнения байт-кода на разнообразных платформах). По существу он предоставляет базовую технологию для создания и исполнения кодов Java.

"Бреши в защите - сейчас они ликвидированы - имели различное происхождение: некоторые возникли из-за простых ошибок реализации, другие имели принципиальный характер", - пояснил Гэри Макгрей, исследователь из Reliable Software Technologies, изучающий вопросы безопасности Java с первых дней существования технологии.

Он добавил, что каждая новая реализация JDK (в начале 1998 года начнутся массовые поставки версии 1.2) порождала новые проблемы с безопасностью, однако найденные ошибки неизменно быстро устранялись. "Чем больше сложность, тем больше вероятность ошибки, - признал исследователь. - Я уверен, найдется еще масса недочетов". По мнению Макгрея, из-за ажиотажного спроса компании Кремниевой долины торопятся с выпуском кода, так что безопасность отходит на второй план.

ВЕСЬ МИР В ПЕСОЧНИЦЕ

Java с самого начала была задумана как технология, с помощью которой однажды написанная программа могла выполняться на любой платформе. И так как Java может работать в системе практически любого типа, и поскольку апплеты Java с удаленного сервера выполняются на клиентской машине, JavaSoft, подразделение корпорации Sun, приложило немало усилий к тому, чтобы решить вопросы защиты на уровне языка программирования. Многие производители любят повторять, что безопасность Java - это не что иное, как оксюморон, но создатели языка с самого начала знали, что вопросы защиты будут иметь решающее значение для судьбы предложенной технологии.

Вся система безопасности Java строится вокруг так называемой модели безопасности Sandbox (этот термин можно примерно перевести как "пожарный ящик с песком"). Эта идея реализована уже в ранних версиях JDK 1.0.x. Sandbox предусматривает ограниченную среду для выполнения апплетов Java, неблагонадежных удаленных кодов. Суть принципа Sandbox состоит в том, что локальные коды считаются надежными, и в их распоряжение предоставляются файлы и другие системные ресурсы, а загружаемые удаленные коды - нет. Им открывается доступ только к определенным ресурсам в пределах Sandbox.

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

Так, например, средство проверки байт-кода должно гарантировать исполнение на клиенте только легитимного кода Java. Когда код достигает клиентской рабочей станции, верификатор проверяет каждый фрагмент на предмет соблюдения ограничений доступа и его целостности.

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

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

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

МИР ЗА ПЕСОЧНИЦЕЙ

JavaSoft постоянно работает над JDK, и, конечно, эта работа состоит не только в латании дыр, но и в совершенствовании самой технологии.

В JDK 1.1.x компания впервые предложила возможность подписывать апплеты. Это означает, что либо создатель кода, либо независимая компания, готовая поручиться за разработчика, проставляет на апплете цифровую подпись, которая служит дополнительной гарантией легитимности кода, поступающего с удаленного узла.

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

Благодаря технологии цифровых подписей, разработчик может применить свой личный ключ к фрагменту кода Java, а затем завизировать его у уполномоченного по выдаче сертификатов (Certificate Authority, CA). Последняя подпись удостоверяет личность держателя пары ключей. Принимающая сторона проверяет сертификат уполномоченного, а также то, что информация об отправителе кода не устарела и не была отозвана.

В опциях защиты и Navigator, и Internet Explorer предусмотрена возможность отбора заслуживающих доверия сертификатов CA. Этот список можно редактировать, удаляя всех уполномоченных, которым пользователь не доверяет.

В модели защиты JDK 1.1.x только код, чей сертификат признается клиентом, может рассматриваться как локальный; в соответствии с принятой политикой в отношении подписей. Все остальные "попадают" в Sandbox с весьма ограниченными правами доступа.

В JDK 1.2 разработчики вышли за рамки традиционной модели Sandbox и предложили более гибкую схему. В новой версии, по мнению Ли Гонга, специалиста по архитектуре защиты в JavaSoft, инструментарий JDK дает пользователю более совершенные методы контроля доступа. "В JDK 1.2 система не загоняет все апплеты в Sandbox, а предоставляет пользователю возможность выбора", - пояснил он.

Кроме того, в JDK 1.2 все локальные коды не считаются заведомо заслуживающими доверия, все они - удаленные или локальные - подвергаются одинаковой проверке. Какие действия разрешены тому или иному фрагменту кода, определяет политика конечного пользователя в отношении защиты. Так, некоторые типы кодов будут помещены в Sandbox, в то время как другие получат более широкие возможности доступа (см. Рисунок 2).

(1x1)

С точки зрения отраслевых экспертов, новый подход к организации защиты может оказаться палкой о двух концах. Гибкость JDK 1.2, безусловно, представляет большой интерес, поскольку дает конечным пользователям и администраторам сетей возможность управлять степенью доступа к Sandbox в зависимости от того, кто подписал или поручился за подлинность апплета. Например, апплетам, подписанным А, будет разрешено читать файлы, апплеты же, подписанные В, будут помещены в Sandbox. Избирательный характер контроля означает, помимо всего прочего, что кто-то должен настроить политику защиты на клиента в соответствии с тем, кто поручился за подлинность апплета, какими ресурсами апплету разрешено пользоваться и какие на него наложены ограничения.

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

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

ПРИГЛЯДИМСЯ К ACTIVEX

До сих пор наше повествование касалось исключительно Java. Это неудивительно, если учесть, как много разработчиков и пользователей взяли на вооружение этот язык программирования компании Sun и, соответственно, сколь многих пользователей беспокоит его безопасность и характер потенциальной угрозы.

Технология ActiveX корпорации Microsoft до сих пор не получила столь широкого распространения, как Java, возможно, из-за того, что она не является кросс-платформенной. Апплеты Java пишутся только один раз, после чего без изменений выполняются на любом компьютере, где есть JVM. Элементы управления ActiveX, напротив, создаются отдельно для каждой операционной системы.

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

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

ActiveX поддерживает некое средство под названием Authenticode, позволяющее разработчику визировать компоненты ActiveX посредством цифровой подписи. Так что при встрече с таким элементом в Web пользователь имеет возможность получить представление об авторе и решить, насколько он заслуживает доверия. Большинство компаний, которые допускают ActiveX до своих сетей, пользуются исключительно подписанными компонентами. Житейская мудрость гласит, что неподписанных элементов надо сторониться, как черт ладана. В случае с неподписанными апплетами Java, какие бы подозрения они ни вызывали у пользователей, модель защиты Sandbox и средство проверки байт-кода значительно снижают риск злонамеренных действий при выполнении программ.

Вы можете предпринять и другие меры, дабы защититься от потенциально опасных элементов управления ActiveX. Например, полностью блокировать ActiveX из браузера Internet Explorer. Пользователям Navigator придется загрузить для этого модуль расширения. Другая мера - проверка благонадежности самого разработчика или поручившегося за него уполномоченного по выдаче сертификатов.

Однако что ни говори, а Microsoft придется добавлять в ActiveX функции, аналогичные Sandbox. Компания не делала на этот счет никаких заявлений, но ей следует дополнить ActiveX чем-то подобным, если она хочет, чтобы ее технология могла претендовать на такой же успех, как Java. Пока же тем, кому позарез нужно выполнять неподписанные коды, ничего не остается, как пользоваться Java.

БДИ!

Итак, пробелы в обеспечении безопасности есть и у Java, и у ActiveX, однако в большинстве случаев компаниям, относящимся к мобильным кодам разумно и принимающим меры предосторожности, бояться нечего.

Прежде всего стратегия компании в области информационной защиты должна быть детально проработана. Тем, у кого нет штатного специалиста по защите, следует проконсультироваться с экспертом в этой области.

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

Одной из первых продукт такого рода на рынок поставила Finjan. Компания предлагает системы, которые анализируют информационное наполнение, содержащее Java и ActiveX, на уровне шлюза Internet и на настольном компьютере (подробнее см. в статье Александра Авдуевского "Серфинг за щитом" в декабрьском номере журнала LAN за прошлый год).

Компания Digitivity разработала AppRouter, который распознает приходящие апплеты и затем загружает фиктивный апплет взамен оригинального. Этот апплет связывается с производимым этой же компанией сервером CageServer, на котором и исполняются оригинальные апплеты Java. Таким

образом, какой бы апплет пользователь ни загрузил с Web, код направляется на специальный сервер, а не к пользователю. Апплет выполняется на этом сервере-посреднике, а результат отображается в браузере. Таким образом, код не взаимодействует ни с одним сетевым ресурсом, кроме специального сервера.

Еще одна компания, Security-7 Software, поставляет продукт под названием SafeGate, осуществляющий анализ Java и ActiveX в режиме реального времени.

Эти продукты, а также встроенные функции последних версий браузеров дают пользователю возможность полностью блокировать все мобильные коды на своем узле. Впрочем, стоит ли прятать голову в песок? Java и ActiveX крайне важны для компаний, работающих в Internet, и стремление самоустраниться от них сейчас может привести к непреодолимому отставанию в будущем.

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

НЕХОРОШИЕ АППЛЕТЫ

Хороший, плохой, злой

Хотя известно только несколько случаев, когда апплеты Java наносили вред вычислительной системе, всегда поучительно знать, какую опасность они в себе несут.

Так называемые враждебные апплеты могут иметь несколько разновидностей. Первая, способная принести максимальный вред, называется иногда "атакующим апплетом". Создатели таких программ используют "дыры" в защите Java, предупреждает Гэри Макгрей, исследователь компании Reliable Software Technologies, долгое время изучавший технологию Java.

К счастью, атакующих апплетов до сих пор не зарегистрировано в сети, но они действительно существуют. "Им не удалось покинуть лаборатории; исследователи обнаружили их существование раньше злоумышленников", - говорит Макгрей.

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

По другому сценарию код Java, допущенный на одну машину, может попытаться замаскироваться под пользующийся доверием локальный код и таким образом получить доступ к локальному диску. "Фактически атакующий апплет действует как хакер, который устанавливает контроль над машиной пользователя и изменяет его систему", - пояснил Макгрей.

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

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

"По нашему глубокому убеждению, 99,5% пользователей Internet - порядочные люди, и злонамеренные коды фабрикует маленькая горстка изгоев, - уверен Энди Бруно, директор по маркетингу компании Digitivity, занимающейся разработкой продуктов для защиты корпоративных сетей от враждебных кодов. - Злонамеренные коды встречаются пока нечасто, тем не менее пользователю следует регулярно просматривать журналы событий и результаты аудита, чтобы иметь представление о том, что же, собственно, происходит в сети".

При нахождении брешей в защите JavaSoft и независимые исследователи быстро их ликвидируют, чтобы кто-нибудь не разработал апплеты, использующие в злонамеренных целях подобные бреши. Однако люди, подобные тем, кто проник в мэйнфреймы Министерства обороны или ЦРУ, достаточно сообразительны, чтобы выявить новые недостатки защиты Java до того, как они будут устранены.

ЗАЩИТА JAVA

Получить полную информацию по вопросам безопасности Java можно, прочитав книгу Гэри Макгрея и Эдварда В. Фелтена "Защита Java: Враждебные апплеты, дыры и противоядия"("Java Security: Hostile Applets, Holes, and Antidotes", Wiley Computer Publishing, 1997).

Ответы на часто задаваемые вопросы относительно защиты Java собраны по адресу: http://java.sun.com/sfaq.index.html.

Для поиска информации о враждебных апплетах и других вопросах защиты Java обратитесь на www.rstcorp.com/~gem/.