ПИШЕМ ПОЛИМОРФНЫЙ ГЕНЕРАТОР
И ДЕТЕКТОР ПОЛИМОРФНОГО КОДА
январь 2001, Sassa для ZF#4
дополнено в апреле 2001
(материалы к статье см. в каталоге \PLUGIN)
sassauk@mail.ru
sassa@apiary.sumy.ua
Содержание
Приложение А. Обзор одного случая некорректного
распространения плаг-инов
Приложение Б. Протокол обработки каталога с вирусами
Использованные источники
Раздаточный материал
Инструменты для детекции вирусов и подписывания файлов
Av.jar Антивирус с плаг-инами
virbase.dat База вирусов для антивируса
Sign.class Инструмент для работы с подписями
Результаты экспериментов
Sign.sig Файл подписи файла Sign.java
pk Открытый ключ, сгенерированный Sign.class
Примечание: секретный ключ не передается, чтоб и не прививать
читателям дурной привычки. разумеется, в подписывании файла Sign.java
нет смысла, поскольку у читателя нет уверенности, что это именно тот
открытый ключ, который автор сгенерировал и хотел передать. Это лишь
иллюстрация.
Исходные тексты утилит
Плаг-ины...................... все файлы .java : Av.jar
Подписчик файлов................................ Sign.java
Эта статья посвящена вопросу создания плаг-инов вообще, и
использованию их в антивирусах в частности. Более абстрактно вопрос
можно поставить так: вопросы реализации динамического наследования.
В конце есть Приложение А, посвященное обзору очень свежего случая
некорректного распространения плаг-инов. Ошибку допустила одна
очень-очень известная компания-производитель ПО.
Слово Plug-In означает "пробка" и означает как правило
необязательный исполняемый код, расширяющий функциональность основного
кода. Смысл создания плаг-инов - распределенное программирование. То
есть, возможность разработки части кода другими людьми, причем с
возможностью соединения исполняемого кода в единое целое во время
работы программы, что гораздо выгоднее, чем на этапе компиляции. Помимо
прочего это несет в себе прямые коммерческие выгоды: код можно
разрабатывать, модифицировать (в том числе исправлять) по частям, что
упрощает и улучшает клиентский сервис.
Удобнее всего кажется описывать принципы создания плаг-инов с точки
зрения Объектно-ориентированного подхода. Даже приведенный RedArcом
пример использования плаг-инов хотя и реализован с помощью приемов
одного только структурного программирования, но не лишен основных
принципов ООП:
- наследование;
- полиморфизм;
- инкапсуляция данных.
а в некоторых источниках к этим принципам добавляют еще и
- разделение классов на классы-манипуляторы и
классы-хранилища
Правда, наследование прослеживается не достаточно четко, если
приходится говорить о наследовании в таком простейшем случае. Но он на
то и простейший, что в нем все реализовано не с позиций полноты, а с
позиций простоты.
Полиморфизм заключается в том, что у некоторого фиктивного (потому
что о классах вообще не шло речи) базового класса PlugIn с единственным
методом - "исполнить" - существует несколько реализаций.
Инкапсуляция данных отсутствует по причине отсутствия самих данных:
по сути своей все разработанные RedArcом плаг-ины - это
классы-манипуляторы.
Итак, процесс работы с плаг-инами можно разбить на такие этапы:
1. проблемы разработки приложения с возможностью
использования плаг-инов
2. разработка самих плаг-инов
2а. безопасное распространение такого кода
3. подгрузка плаг-инов: динамическое наследование
Принцип создания плаг-инов в том, что разрабатывается иерархия
классов, а основному коду достаточно знать только базовый класс, от
удачности формализации которого зависит успех всего приложения.
Функциональность плаг-ину придают наследники базового класса:
конкретные "вставки" для конкретной "дырки".
Последовательность работы с плаг-инами, описанная выше, не отражает
этапы процесса разработки приложения. Поэтому в некотором смысле третий
пункт является, все же, вторым по важности - поскольку он касается
создания ПО, в то время как пункт 2 - это уже этап _модернизации_ его,
поэтому их можно рассмотреть и в другом порядке.
Итак, загрузка плаг-инов - это вопрос создания объекта неизвестного
приложению класса. Искусительно привлекательно выглядит идея научить
приложение понимать формальное описание класса, чтобы при загрузке
приложение могло интерпретировать некоторый язык и правильно
инициализировало объект. Однако практические реализации этой идеи пока
еще далеки от идеала.
Отметим все же, что для описания классов-хранилищ уже разработаны и
довольно широко используются языки формального описания данных:
XML (рекомендация консорциума W3C от 10 Февраля 1998 и
рекомендация W3C от 6 Октября 2000, на основе ISO 8879 от
1986),
ASN.1 (CCITT рекомендации X.208 и X.209; а также адаптации
институтом ISO: ISO 8824 и ISO 8825, изданных в 1987),
EDIFACT (ANSI X.12),
и некоторые другие менее распространенные.
Таким образом, приложение довольно легко может оперировать такими
данными, структуру которых оно не знает до того, как поступит описание
на формальном языке (уже _после_ компиляции приложения). Интерпретаторы
этих языков довольно просты и легко подстраиваются под конкретные
нужды. Тогда приложение может читать и модифицировать те данные,
которые оно понимает, не искажая при этом тех данных, которых оно не
понимает. Такая гибкость позволяет говорить о динамическом наследовании
классов-хранилищ.
Описание же классов-манипуляторов на формальных языках затруднено.
Тем не менее, некоторые программные продукты включают в себя базы
данных объектов, сервер которой умеет создавать неизвестные ранее
классы на основании его формального описания (технологии CORBA и COM
отличаются тем, что они не имеют самого описания методов класса и
используют уже готовый откомпилированный код). Одной из реализаций
подобного рода является процессор языка Java. Именно ввиду простоты
использования этого сервера объектов пример приложения, работающего с
плаг-инами, написан на этом языке. Помимо этого, язык Java обладает еще
рядом преимуществ, о которых мы будем говорить позже - собственно, не
сам язык, а набор готовых инструментов.
На практике же зачастую отказываются от описания класса на
формальном языке, и пишут классы для каждого специального случая (для
каждого приложения) отдельно. Затем в .DLL (если речь идет о Windows)
помещается своеобразный "сервер" - функция, которая умеет создавать
объект нужного класса; естественно, структура класса известна при
компиляции .DLL. То есть, это не решает проблемы создания нужного
объекта, так как каждая из таких .DLL умеет создавать только объекты
тех классов, которые она знает. Отметим, что значительно большей
гибкостью в этом плане обладает сервер классов процессора Java.
Конечно же, программы тупы, и не могут знать, как использовать тот
или иной код. Поэтому обычно использованию плаг-инов предшествует
процедура регистрации, чтобы существующее программное обеспечение
узнало о существовании такого кода, а также о параметрах его запуска и
возможностях использования. Но в прилагаемом к статье антивирусе этой
процедуры не выполняется в открытом виде: регистрация плаг-инов
происходит сама собой, на лету. Точнее, ввиду специфичности
использования плаг-инов в этой реализации, они являются не такими уж и
необязательными, и поэтому программа вправе требовать присутствия
отдельных ее элементов.
В частности, процесс работы с плаг-инами в прилагаемом антивирусе
иллюстрирует оригинальную идею их использования. Класс Av является лишь
процессором, конечным автоматом. Основная его функция - работа с
файлами, а также подгрузка и исполнение плаг-инов. Плаг-ины являются по
сути состояниями автомата Av, которые, получая данные (лямбда в машине
Тьюринга), анализируют их и возвращают процессору указание, в какое
состояние нужно перевести автомат (возвращают имя класса, который нужно
исполнить дальше; извлекают соответствующую ячейку из строки таблицы
состояний в примере с машиной Тьюринга) и передают процессору те
данные, которые должно получить на вход новое состояние. Процессор Av
умеет извлечь из данных конечного состояния всю необходимую информацию:
диагноз, образ исцеленного файла, если он был исцелен, и прочее.
Итак, Av загружает начальное состояние автомата - класс GP -
создает один объект этого класса и передает ему для анализа битовый
образ файла. Состояние GP проводит классификацию файла (на данном этапе
- просто вызов единственного инструмента, который он знает), и в
зависимости от его типа вызывает соответствующий инструмент:
разархиватор, анализатор СОМ-файлов, анализатор ЕХЕ-файлов (если
хочется разделить их на разные), анализатор VB-скриптов (а может,
анализатор скриптов вообще, который сначала решит, что это за скрипт),
и так далее. Причем, существующий инструмент SignatureSearch не
изменится при расширении классификации файлов усовершенствованным
объектом GP.
GP просит Av загрузить нужный ему плаг-ин, Av ищет его среди
загруженных, и если не нашел, подключает его извне. Механизм загрузки
только нужных плаг-инов дает дополнительные преимущества: времени на
загрузку исполняемых дополнений тратится ровно столько, сколько
дополнений будет использоваться, а одноразовая инстантиация ускоряет
процесс использования плаг-ина в дальнейшем.
При создании объекта плаг-ин имеет возможность прочитать настройки
антивируса и преобразовать вирусную базу к собственному внутреннему
формату, если необходимо.
Итак, SignatureSearch локализует сигнатуры вирусов и передаст
параметры, необходимые для лечения, в другой плаг-ин: PatchHealer. Av
отыскивает этот плаг-ин, загружает его, и передает информацию,
переданную предыдущим анализатором. PatchHealer после исцеления снова
запускает антивирус в начальное состояние, чтобы последовательно искать
новые вирусы. Цикл будет повторяться конечное число раз, в соответствии
с числом вирусов в теле жертвы. Окончательно ядро антивируса - Av -
выполнит запись тела исцеленной программы.
Такой подход позволил выделить граф исполнения программы в
отдельные, довольно мелкие участки кода, которые можно заменять,
объединять, разделять и удалять из системы по желанию разработчика или
в соответствии с настройками пользователя.
Заметим, что иллюстрировалась лишь возможная и на взгляд автора
чрезвычайно гибкая архитектура приложения со сложной логикой, которую
можно изменять в процессе усовершенствования программного продукта.
Реализованная логика работы примера вызвала споры о ее корректности как
антивируса, поскольку данный подход лечит вирусы в той
последовательности, в какой они будут исполняться. Существуют
противоречивые мнения насчет корректности этого алгоритма. Поэтому
отметим лишь, что редакция ЗФ планирует посвятить найденным ответам на
некоторые вопросы алгоритма корректного лечения отдельную статью, или
даже цикл. Но к плюсам реализации следует добавить то, что все же эту
логику в дальнейшем можно перепрограммировать в соответствии с новыми
взглядами на корректность исцеления.
Класс Belkodav является примером анализатора полиморфного кода и
предназначен для ловли вирусов, сгенерированных мотором VCG.1 (Belka).
Идее построения подобных автоматов посвящена отдельная статья - "Пишем
полиморфный генератор и детектор полиморфного кода" - этого выпуска
"Земского Фершала". Отметим снова, что это один из самых примитивных
автоматов такого рода.
Теперь вернемся к вопросам разработки плаг-инов.
Как было сказано, ключевым моментом является использование общего
дерева наследования классов. Нам кажется, именно при динамическом
наследовании наиболее наглядно представляется суть наследования в
объектно-ориентированных моделях, и именно поэтому
объектно-ориентированная модель описывает такой способ использования
исполняемого кода четче всего.
Так, существующие модули (будь то ядро или другие плаг-ины) не
могут "узнать" без перекомпиляции о том, что плаг -ин был переписан
заново и что теперь он имеет другую структуру. Но именно наследование
позволяет старым классам использовать новые версии кода по-старому, при
этом получая те же самые ответы на запросы, как и при использовании
старых версий. Одновременно новые плаг-ины, знакомые с новшеством,
могут воспользоваться нововведениями.
Например, в примере антивируса SignatureSearch возвращает в виде
результата расширенную информацию: объекты ResultPatch, которые помимо
обычной информации о наличии вредоносного кода, переходов атвомата
лечения в новое состояние, диагноза, содержат дополнительные данные,
характеризующие метоположение вредоносного кода. Тогда PatchHealer,
знакомый с новым форматом результатов поиска (и который, собственно,
только такой формат и понимает) пользуется этими данными для успешного
исцеления.
О распространении дополнений можно сказать, что защита их от
злонамеренной модификации необязательна, хотя любой разработчик все же
заинтересован в этом. (Защита от ошибок при передаче или хранении - это
отдельный вопрос, поскольку там возможно использовать контрольные суммы
любого подходящего рода). Мы можем лишь предложить некоторые
рекомендации о реализации этого пункта, поскольку по нашему мнению
наиболее надежным является использование криптографических методов для
защиты кода, а использование сильных методов вовлекает законодательство
об интеллектуальной собственности на существующие реализации этих
методов. В то же время автор не считает себя достаточно
квалифицированным для создания достаточно продуктивных систем защиты в
короткие сроки, а тем более всего лишь для примера в журнале. В
частности, необходимо умение продуктивной манипуляции простыми числами.
Здесь автор отсылает читателя к курсам лекций по модульной алгебре, а
также к спецификациям систем шифрования с открытым ключом, которые
можно найти на сайте рабочей группы P1363 (
http://grouper.ieee.org/groups/1363). Особенное внимание рекомендуется
обратить на документы "IEEE P1363: Standard Specifications For Public
Key Cryptography", а также "Diffie-Hellman and MQV Key Agreements" ANSI
X9.42 и "Elliptic Curve Digital Signature Algorithm (ECDSA)" ANSI
X9.62, драфты которых доступны на этом сайте свободно [1,2,3].
Возможности таких систем обсуждаются на доступном английском языке в
[4] - собственно, обзор для тех, кто не желает вникать в детали
алгоритмов.
Отметим также, что патент на коммерческие реализации RSA, например,
истек 6 Сентября 2000 года [5].
Но если использовать язык Java, то можно заимствовать из JDK
классы, позволяющие генерировать и проверять электронную подпись с
помощью алгоритмов шифрования с открытым ключом. Это неотъемлемая часть
самого процессора Java, поскольку он должен уметь проверять сигнатуры
подписанных классов, чтобы удостовериться в том, что класс поступил от
нужного производителя ПО. Однако, поскольку кроме классов с антивирусом
поставляются и другие файлы - базы сигнатур, настроечные файлы - то
даже в случае с Java кажется разумным создать приложение для подписи и
проверки достоверности произвольных файлов, не говоря уже о том, что
для других языков подписывать нужно было бы уметь и плаг-ины; однако,
это не проблема, коль скоро утилита умеет работать с произвольными
файлами.
Прилагаемая к статье утилита Sign написана на Java, и умеет
генерировать пары ключей, подписывать произвольные файлы и проверять
достоверность подписи. Конечно, эти процедуры нужно было бы включить в
сам антивирус, но это ведь не единственная черта, которую нужно
добавить в него, чтобы он стал похож на коммерческий продукт. Для
примера показалось достаточным создания отдельного приложения. Поэтому
часть работы должна быть выполнена вручную; а именно - электронные
подписи файлов, полученных предположительно от разработчика антивируса,
должны быть проверены с помощью этой утилиты, а только затем помещены в
каталог с самим антивирусом, чтобы он мог в дальнейшем пользоваться
ими.
Программа умеет генерировать два ключа - открытый и секретный.
Открытый ключ (Public Key), как и сама программа, распространяются
свободно. Секретный ключ (Закрытый ключ; Secret Key; Private Key)
должен оставаться у производителя ПО и является залогом безопасности.
Производитель подписывает файлы с помощью секретного ключа, и
поставляет совместно с файлами соответствующие им подписи.
Пользователь, получив файл с подписями, и обладая открытым ключом
производителя, проверяет достоверность подписи. Если подпись не
сходится, то либо файл, либо подпись испортились при передаче, а,
возможно, были заменены злоумышленником. До тех пор, пока злоумышленник
не обладает секретным ключом производителя, и пока он не может передать
пользователю свой собственный открытый ключ, он не может генерировать
корректную подпись. Пользователь должен либо получать открытый ключ
производителя из надежных источников (коим Internet не является; но
которым является сеть дилеров этого антивируса), либо открытый ключ
должен быть подписан заведомо надежным ключом.
Программа использует алгоритм DSA (рекомендация NIST), сравнимый по
силе с широкоизвестным RSA, но годится только для создания и проверки
электронных подписей (именно невозможность шифрования произвольных
данных привело к менее жестким ограничениям патентного законодательства
на коммерческое использование этого алгоритма). Именно "использует",
поскольку JDK 1.2.2 содержит все необходимые классы.
Генерация ключей и подписывание файлов занимает довольно много
времени (около минуты на каждую из этих операций на PIII, 550MHz,
128МБ, Win98), поэтому просим терпения. Проверка же проходит
практически мгновенно (на той же машине этот процесс занимает менее
секунды).
О правильности проверки подписи написаны толстые документации, но
мы не станем углубляться в них слишком подробно. Отметим лишь, что
интересующиеся могут для начала ознакомиться со стандартами,
касающимися Public Key Infrastructures. В частности, многие вопросы
этой темы затронуты и расширены в семействе стандартов X.500 [6].
В реальной жизни пользователю необходимо знать, достоверен ли
открытый ключ, которым он обладает. Это можно узнать, проверив
авторизованность источника, из которого он получен, а также сообщения
владельца соответствующего закрытого ключа - он мог отказаться от
использования этого ключа ввиду каких-нибудь причин - например, его
взлома. Однако даже если ключ был получен из ненадежного источника, но
к нему прилагается подпись, изготовленная с помощью достоверного ключа,
то первый ключ может также считаться надежным. Это позволяет
пользователю (в данном случае - пользователю ПО) лишь один раз
воспользоваться надежным источником, из которого он должен получить
программу и текущий открытый ключ изготовителя. В дальнейшем
изготовитель может передавать обновления ПО, дополнения к нему - да
все, что угодно, даже новые открытые ключи, и даже по ненадежным
каналам, если каждый файл подписан.
Скажем, надежность ключа составляет 2 года (реальные ключи на
современной технике взламываются за время, сравнимое с возрастом
Вселенной). Для безопасности сроки использования укорачиваем до
полугода. Так, производитель раз в пол-года генерирует новую пару
ключей, подписывает старым, и рассылает открытый ключ пользователям.
Отныне все, что он будет отправлять, должно быть подписано новым
ключом, и даже в случае взлома старого ключа, информация, подписанная с
его помощью (возможно, злоумышленная) должна быть игнорирована
пользователем.
О случаях "досрочного" взлома и о других деталях обращайтесь к
стандартам и спецификациям. Здесь же была изложена лишь основная идея.
В дополнение можно сказать еще пару слов о назначении привилегий
плаг-инам. Не всякое дополнение должно иметь доступ к файлам, например,
или к сети, а наличие доступа к этим ресурсам несет в себе риск.
Разграничение доступа, как правило, запрограммировано жестко в код
"основного" приложения, однако, существуют схемы динамического
ограничения действий модулей. В этом смысле Java снова выступает как,
пожалуй, самый развитый инструмент манипуляции распространяемыми
модулями [7]. Идея, заложенная в эту платформу, заключается в том, что
вместе с кодом распространяется некий сертификат атрибутов, содержащий
необходимые привилегии доступа, и встроенные в Java менеджеры
безопасности (которые могут быть замещены приложением собственными
менеджерами безопасности) отслеживают доступ к ресурсам, и в случае
запрета доступа генерируют исключительные ситуации.
Для простоты примера такая система не реализовывалась.
Таким образом были рассмотрены основополагающие принципы создания
приложений с возможностью их усовершенствования "на лету". Надеемся,
примеры программ достаточно полно иллюстрируют изложенные идеи.
Приложение А.
Обзор одного случая некорректного распространения
плаг-инов.
После того, как статья уже была сдана в номер, пришло очень важное
сообщение, касающееся нашей темы [8], что и привело к появлению этого
Приложения. Однако, заметим, что радужные перспективы, нарисованные в
указанном источнике фирмой Майкрософт не такие уж и радостные на самом
деле. Фирма лишь пытается спасти лицо. Существует ряд мер
предосторожностей, которые они могли выполнить, но которых они не
выполнили.
В двух словах проблема выглядит так: пользователи верят только
ограниченному набору открытых ключей (в частности, ключу фирмы
VeriSign, поставляемом со всеми распространенными браузерами; например,
в Netscape в меню Communicator | Tools | Security Info | Certificates |
Signers есть список всех имеющихся сертификатов открытых ключей и можно
настроить доверие каждому из них; в этом списке наличествует и
несколько ключей VeriSign), а по ошибке фирма VeriSign подписала
открытый ключ якобы фирмы Майкрософт, но, как выяснилось, таковым не
являющийся. Тем не менее, исполняемый код, подписанный с помощью этого
ключа, будет "заявлять", что он подписан фирмой Майкрософт, потому что
имя именно этой фирмы указано в открытом ключе. Какой же пользователь
не подключит обновление ОС Windows, подписанное самим "изготовителем",
да еще и ключ которого подписан доверенным лицом! В результате
злоумышленник, который смог обмануть VeriSign, вполне может
распространять вместо обновлений операционной системы шпионы и
троянские приложения, и они будут санкционированно установлены в
систему!
Для решения этих проблем еще в самом начале разработки стандартов
PKI были введены так называемые списки отзыва ключей. Таким образом,
кроме того, что подпись должна совпасть, подписывающий ключ не должен
быть в общедоступных списках отзыва. Если же ключ в таком списке, то с
ним что-то произошло (взлом; кража секретного ключа; ошибки в
параметрах сертификата) и ему верить больше нельзя. Фирма VeriSign
незамедлительно поместила фальшивые ключи в список отзыва, как только
узнали о бреши в системе безопасности (списки отзыва VeriSign находятся
здесь: http://crl.verisign.com/). А вина фирмы Майкрософт состоит в
том, что даже обладая функцией проверки этих списков, приложения и сама
операционная система не вызывают ее по умолчанию перед выполнением
загруженного извне подписанного кода (по их собственному косвенному
признанию, только сейчас они "включили проверку списков отзыва в MSIE"
[8]) - компоненты ActiveX, обновления ОС и т.д. Эффект можно только
представить...
В противовес высказываниям фирмы Майкрософт о том, что, дескать,
VeriSign не включила информацию о списках отзыва в ключ [8], можно
сказать, что эта информация является опциональным полем [6], и может
быть введена жестко в конфигурацию соответствующего ПО на этапе
компиляции. Что и предлагает делать VeriSign в своем лицензионном
соглашении [9]. Всякий, кто использует их сертификаты, связан этим
соглашением.
Однако, чтобы VeriSign, хотя она и предстала таким себе козлом
отпущения, не показалась достойной жалости, еще два слова: были
успешные попытки создать персональный сертификат с именем пользователя
Bill Gates уже после опубликования этой бреши. Это, конечно, не так
страшно для остальных пользователей, как ключ производителя ПО, но
политика компании "плати - и будь хоть Черчиллем" должна вызвать
настороженность и к остальным фирмам.
Приложение Б.
Протокол обработки каталога с вирусами
beasts\NONTSR.ASM : OK
beasts\NONTSR.COM : detected - Khizhnjak.460
: healed - Khizhnjak.460
: OK
beasts\RA112.COM : detected - RedArc.112
: healed - RedArc.112
: OK
beasts\BELKA.000 : detected - BELKA.v1.dropper
: healed - BELKA.v1.dropper
: OK
beasts\BELKA.000 is not allowed to modify.
Change its access attributes or remove it.
beasts\BELK_1.COM : healed - BELKA.v1.parent
: OK
beasts\BELK.COM : detected - BELKA.v1.dropper
: healed - BELKA.v1.dropper
: OK
beasts\BELKA.COM : detected - BELKA.v2.dropper
: healed - BELKA.v2.dropper
: OK
beasts\BELKA_1.COM : healed - BELKA.v2.parent
: OK
beasts\BELKA_2.COM : unrecoverable - BELKA.v2.child
Использованные источники
1. IEEE P1363: Standard Specifications For Public Key
Cryptography. // http://www.ieee.org/
2. Diffie-Hellman and MQV Key Agreements. ANSI X9.42 //
http://www.ieee.org/
3. Elliptic Curve Digital Signature Algorithm (ECDSA).
ANSI X9.62 // http://www.ieee.org/
4. Cryptography FAQ //
http://www.landfield.com/faqs/cryptography-faq/part06/
5. RSA Security - Behind the Patent. //
http://www.rsasecurity.com/solutions/developers/total-solution/faq.html
6. ITU-T Recommendation X.509. 4-th Edition Draft. //
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X509_4thEditionDraftV7-.pdf
7. Wayne Jansen, Tom Karygiannis. Privilege Management of
Mobile Agents. // National Institute of Standards and
Technology,
http://www.itl.nist.gov/div893/staff/jansen/pp-attCert-final.pdf
8. Microsoft Security Bulletin MS01-017. Erroneous
VeriSign-Issued Digital Certificates Pose Spoofing Hazard //
http://www.microsoft.com/technet/security/bulletin/MS01-017.asp,
28 Марта 2001.
9. VeriSign Certification Practice Statement. //
http://www.verisign.com/ , 30 Мая 1997.
--
Все источники являются официальным продуктом их уважаемых
производителей и защищены законодательством, как указано в самих
документах
Sassa
sassauk@mail.ru
sassa@apiary.sumy.ua
(cJ 2000-2001, Sassa, Apiary Ink. Especially for ZF#4
|
