Злонамеренный мобильный код
Появление мобильного кода стало важным событием в процессе развития Internet от статического набора документов до, случайным образом генерируемой среды, которой она стала на сегодняшний день. Развитие современных технологий, основанных на динамических данных, на сегодняшний день уже стало основой обработки информации. Однако на этапе развития акцент делался не на повышение надежности клиентских вычислительных моделей, а на расширение использования динамических документов HTML (DHTML), таблиц стилей и повышение производительности сценариев серверных приложений. (Правда, на это можно возразить, что сама обработка данных происходит все же на клиентском компьютере, однако подобный спор требует углубления в архитектуру самого Web-браузера.) В любом случае мобильный код, передающийся по сети на узел назначения, на сегодняшний день остается важнейшей частью фундамента Internet. Механизмы поддержки двух доминирующих парадигм мобильного кода, язык Java компании Sun и элементы управления ActiveX компании Microsoft, встроены во все браузеры, поэтому их изучение крайне важно для обеспечения безопасности любого клиента Internet. ActiveX и Java часто сравниваются между собой. Делать этого не стоит, может не хватить целого блога!-) Лучше просто обсудить реальные изъяны, обнаруженные в каждом из этих подходов. Тем, кто интересуется подробным техническим описанием преимуществ и недостатков обеих моделей разработки мобильного кода с точки зрения их безопасности, можно порекомендовать статью Девида Хопвуда – «A Comparison Between Java and ActiveX Security», которую можно найти по адресу – http://www.users.zetnet.co.uk/hopwood/papers/compsec97.html (см. www.users.zetnet.co.uk).
Элементы ActiveX компании Microsoft
Элементы управления ActiveX являются результатом повторной попытки фирмы Microsoft разработать модель мобильного кода. Их часто описывают как приспособленную для Web технологию создания документов со связыванием и внедрением объектов (Object Linking and Embedding — OLE). На самом деле это сильно упрощенная трактовка набора интерфейсов, спецификаций и претендующих на исключительность парадигм разработки, входящих в модель СОМ компании Microsoft (COM — Component Object Model), которая и составляет основу технологии ActiveX. В то же время подобные упрощения способствуют лучшему пониманию. Приложения ActiveX, или элементы управления (control), могут создаваться для выполнения определенных задач (таких как воспроизведение видео- или звукового файла). Их можно поместить на Web-страницу, и тогда эти программы будут выполнять свои функции при ее просмотре точно так же, как технология OLE поддерживает операцию вставки электронных таблиц Excel в документы Word.
Обычно файлы с элементами управления ActiveX имеют расширение .OCX (исключением являются элементы управления ActiveX, написанные на Java). Они встраиваются в Web-страницы с помощью дескриптора <OBJECT>, в котором указано, откуда элемент управления нужно загрузить. Когда браузер Internet Explorer обрабатывает Web-страницу с внедренным в нее элементом управления ActiveX (или несколькими элементами управления), сначала он обращается к локальному системному реестру. Там он пытается определить, имеется ли на компьютере требуемый компонент. Если это так, Internet Explorer отображает Web-страницу, загружает элемент управления в свое адресное пространство и выполняет его код. Если необходимый элемент управления не найден, Internet Explorer загружает его из того места, которое указано в дескрипторе <OBJECT>, и устанавливает на компьютере пользователя. Кроме того, с помощью сертификатов Authenticode браузер выполняет верификацию автора кода, а затем запускает его. По умолчанию элементы управления кэшируются в каталоге \windows\occache.
Не выходя за рамки вышеописанной модели, хакер-программист может создать элементы управления ActiveX, которые будут выполнять на компьютере пользователя практически все, что захочется их автору.
Что же может помочь в такой ситуации?
Сертификаты Authenticode компании Microsoft. Эта подсистема позволяет разработчикам использовать механизмы шифрования и создавать для своего кода криптографические подписи, которые перед запуском элемента ActiveX будут аутентифицироваться браузером Internet Explorer и приложениями сторонних производителей (одним из таких производителей является компания Verisign Corporation).
Как же на самом деле используются сертификаты Authenticode?
В 1996 году программист по имени Фред Маклейн написал элемент управления ActiveX, который корректно выключал пользовательский компьютер, если он работал под управлением операционной системы Windows 95 с улучшенным управлением электропитанием. Для этого кода, названного автором Internet Exploder (взрывная машинка Internet), компания Verisign выдала ему подлинный сертификат, после чего Маклейн разместил программу на собственном Web-узле. В результате недолгих дебатов о целесообразности такой публичной демонстрации модели безопасности Authenticode, компании Microsoft и Verisign лишили Маклейна сертификата, обвиняя его в нарушении обязательств, на которых основан этот документ. Элемент Exploder работает как и раньше, но при этом он информирует любителей попутешествовать в Internet о том, что код не зарегистрирован, и дает им возможность отказаться от его загрузки.
Автор предоставляет читателю возможность решить самому, можно ли в этом случае считать, что сертификаты Authenticode выполняют свои функции. Но не стоит забывать о том, что Маклейн мог бы написать код, выполняющий намного более опасные действия, чем простое выключение компьютера. К тому же он мог проделать все это абсолютно скрытно. На сегодняшний день элементы ActiveX по-прежнему являются важным механизмом, который обеспечивает успешное функционирование многих Web-узлов. Однако при этом нередко возникают дополнительные проблемы, некоторые из них при тщательном прогугливании можно найти!-)
Изъяны в системе защиты Java
В 1990 году компания Sun Microsystems решила создать парадигму программирования, которая помогла бы решить многие проблемы разработки программ, стоящие перед их создателями еще со времен зарождения вычислительной техники. В результате одним выстрелом удалось убить двух зайцев: создать новый язык Java и попутно решить многие традиционные проблемы обеспечения безопасности. Большинство людей полагают, что язык Java безопасен на все 100%, поскольку с самого начала был задуман как нечто исключительное. Это мнение в значительной мере подкрепляется маркетинговой политикой компании Sun. Конечно же, обеспечить абсолютную безопасность невозможно. Однако пути ее повышения, применяемые в Java, несомненно, представляют определенный интерес.
Java — тщательно продуманный язык, позволяющий программистам избежать многих ошибок, которые могут привести к таким проблемам безопасности, как переполнение буфера (Dos). На этапе компиляции и выполнения виртуальной машиной Java (JVM — Java Virtual Machine) и встроенным механизмом проверки байт-кода осуществляется строгий контроль типов, что помогает защитить используемые программой области памяти. Кроме того, в языке Java не поддерживается прямой доступ к памяти и манипуляция ею с помощью указателей, позволяющих программисту управлять использованием и загрузкой кода.
Кроме того, в JVM есть встроенный диспетчер безопасности (Security Manager), выполняющий контроль доступа к системным ресурсам. Его работа основана на политике безопасности, задаваемой пользователем. Наряду с проверкой типов эти концепции создают ограничительный барьер, не позволяющий коду Java выполнять привилегированные действия без явного согласия пользователя. В дополнение ко всему вышесказанному язык Java позволяет использовать сертификаты, определяющие степень «надежности» загруженного извне кода или доверия к нему. Основываясь на своем доверии к данному сертификату, пользователь принимает решение, запускать данный код или нет (что во многом напоминает работу Authenticode).
И наконец, спецификация Java, с которой без проблем можно познакомиться по адресу http://java.com (см. java.com), открыта для широкой общественности. Очевидно, такая открытость для критики и анализа приводит к естественному отбору и избавлению от различных недостатков.
Теоретически эти механизмы преодолеть крайне сложно (фактически для многих из них имеется формальное доказательство их безопасности). Однако на практике механизмы безопасности Java были взломаны много раз. Это произошло по той же хорошо известной причине, которая заключается в том, что в процессе реализации нарушаются принципы, заложенные при проектировании.
Как итог: мы по-прежнему лезем в настройки браузера, дабы отключить поддержку Java и элементы ActiveX, потому что так нам сказали и потому что так безопаснее, но не кому и в голову не может прийти что за этими технологиями стоят толпы людей и годы разработок.
Твитнуть
в данном случае мобильный код описывается не в контексте вирусов для моб. телефонов
Скоро вирусы вообще станут писать и на TV-тюнеры, чтобы каналы воровать
.
да- да ! Оно так и есть ! Моя мать закончила учиться лет 12 назад на компьютерщика.. и теперь говорит что и тогда тоже были вирусы.