Можно ли доверять Java?

Использование Java дает вам прекрасную возможность "оживить" свою сеть intranet, однако представляете ли вы, с какими проблемами защиты вам придется столкнуться? Гэри Макгроу, соавтор книги "Безопасность Java: враждебные апплеты, дыры и противоядия" ("Java Security: Hostile Applets, Holes and Antidotes"), поможет вам ответить на этот вопрос. Предлагаем вашему вниманию выдержки из его интервью еженедельнику Network World.

Какую угрозу представляет Java для операторов intranet?

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

Проблема заключается вот в чем: если Web-браузер позволяет вам загружать исполняемый код - т. е. дает возможность использовать Java и ActiveX и все эти "модные штучки" - то как вы сможете предотвратить загрузку опасного кода вашими пользователями? В конце концов, может быть вы хотите дать им возможность использовать Java-апплет, написанный вами для своей сети intranet, но при этом запретить использовать апплеты со стороны. Так что необходимо выяснить, откуда поступают ваши данные. Некоторые пытаются выйти из положения, останавливая Java- или ActiveX-программы на брандмауэре. Существует, однако, ряд доказательств того, что это сделать невозможно.

Почему так?

Потому что обычный подход заключается в том, чтобы сканировать весь входящий трафик на 80-м порту HTTP с целью выявить такие элементы, как теги апплетов. Но этого недостаточно, чтобы остановить Java-апплеты, потому что вы можете получить байт-код (результат компиляции исходного кода Java) и другими способами. Для примера представьте, что файл апплета .class выдает себя за изображение. Вы считаете, что это изображение, и оно загружается в кэш, после чего программа просмотра выходит из строя. Однако это неважно - оно все еще находится в кэше. И если позже вы сможете его активизировать, то проблемы возникнут снова.

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

Байт-код Java необходим для переноса небольшого элемента, называемого "магическим числом", которое в шестнадцатеричной форме выглядит как CAFE BABE. Эти два байта должны присутствовать в начале каждого байт-кода Java. Так что вы могли бы, вероятно, проследить наличие магического числа в трафике через каждый порт, однако такая процедура очень напоминает поиск иголки в стоге сена.

Отсюда следует, что нельзя обезопасить свою intranet от Java-атак с помощью брандмауэра?

Это действительно так. На эту тему есть хорошая техническая статья "Blocking Java Applets at the Firewall", написанная Дэвидом Мартином из Бостонского университета в соавторстве с С. Раджагопаланом и Авиэлем Рубином _ сотрудниками компании Bellcore (вы можете найти ее по адресу www.rstcorp.com/javasecurity/links.html). Эта статья, в основном, написана в помощь производителям, которые убеждены в том, что можно остановить Java-апплеты путем сканирования трафика на 80-м порту.

Прежде чем ответить на вопрос, как можно себя защитить, объясните, почему Java-атаки считаются такими опасными?

Прелесть языка Java в том, что он кросс-платформенный, т. е. байт-код Java может исполняться на любой платформе, поддерживающей Java Virtual Machine, но именно это и делает Java таким опасным. Если имеется, например, Java-вирус (пока такого еще не встречалось, но поскольку Java является языком программирования, это вполне возможно) или атакующий Java-апплет, то он сможет работать на любой платформе. Так что это не будет обычная атака, которая, скажем, направлена только на системы Solaris или HP-UX. Она может быть направлена на любую платформу, на которую перенесен язык Java.

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

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

Таким образом, в модели защиты Java апплетам не разрешается совершать опасные для вас процедуры, и в целом это работает. Проблема в том, что эта модель также срабатывает и в сети intranet. Допустим, я хочу написать Java-апплет для intranet, который бы позволил клиентам Macintosh, Wintel и Unix получить доступ к базе данных. Это, однако, невозможно, поскольку в Java нельзя осуществлять доступ к файлам из апплетов - и точка.

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

Цифровые подписи позволят вам выпустить Java-апплеты за пределы своих "песочниц" (sandbox). Те, кто пишет Java-апплеты для сетей intranet, реально заинтересованы в этом, поскольку для них сфера применения апплетов выходит далеко за пределы простого отображения анимации на экране. Однако проблема в том, что структура цифровой подписи должна быть совершенной, иначе вы останетесь уязвимы.

Java-программы обычно достаточно просты с точки зрения защиты, потому что вы не доверяете никаким апплетам, даже тем, которые написаны вами. Однако с появлением подписанного кода эта ситуация меняется.

Вначале вы сказали, что Java - это всего лишь часть проблемы: еще большая опасность связана с исполняемым кодом вообще. Можно ли утверждать, что этим угрозы безопасности исчерпываются?

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

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

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

Способ, позволяющий реализовать этот принцип в наборе JDK 1.11, состоит в том, что апплеты полностью выводятся из "песочницы". То есть модель защиты не применяется. Если это подписанный код, и вы даете ему разрешение на работу, он может делать все. Однако в будущем предполагается ввести контроль доступа, и эта возможность должна появиться в JDK 1.2.

Идея контроля доступа актуальна, поскольку позволяет вам сказать: "Если этот апплет подписан моим другом Бобом, я позволю ему считать конкретный файл, и больше ничего". Это хорошо. Но сложность в том, что приходится очень тщательно выверять политику защиты. Закрутив гайки слишком сильно, вы рискуете сорвать резьбу.

Чего следует ожидать в будущем?

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

Не могли бы Вы остановиться подробнее на различных угрозах безопасности?

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

Как мы можем безопасно использовать Java?

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

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

Еще одно правило: внимательно следите за сообщениями об ошибках в защите. Полезно для этого посетить узел CERT (http://www.cert.org) и подписаться на его предостерегающие сообщения. Однако проблема в том, что этот узел часто на два-три месяца отстает от хакеров, поскольку прежде, чем предупреждать пользователей о прорехах в защите, он ожидает выпуска "заплаток" для них.

Если вы озабочены состоянием защиты и действительно представляете собой хорошую мишень, то следует более внимательно следить за всем, что происходит. Мы предоставляем бесплатную службу для тех, кто, в частности, обеспокоен проблемой защиты в Java; мы располагаем списком рассылки, куда можно занести свою фамилию и регулярно получать информацию с узла http://www.rstcorp.com/java-security.html, дополняющего нашу книгу.

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