 |
Sendmail и электронная почта 8 глава
|
|
|
|
Часто такие ошибки проявляются не сразу. Предположим, программист считает, что 1024 байт, которые он выделил под временный буфер, будет вполне достаточно во всех случаях. Это допущение представляет собой потенциально слабое место в программе. Если программа работает в однопользовательской ОС, то сбой может привести к зависанию компьютера; но в многопользовательской и сетевой ОС последствия могут быть более серьезными. Известный вирус Морриса использовал, в частности, этот алгоритм для проникновения в защищенные системы.
Для рассмотрения механизма атаки возьмем программу под названием "rabbit.c":
Во фрагменте программы функция принимает строку как один из нескольких аргументов, имеет локальный буфер ограниченного размера и использует вызовы типа strcpy() или sprintf(). Как происходит вызов функции process()? Стек (будем считать, что он растет вверх) перед вызовом функции выглядит следующим образом:
Параметры функции передаются через стек - туда заносятся указатели на параметры или сами параметры (в нашем случае это один указатель на строку), а вызванная функция извлекает их оттуда. Этим занимается код, сгенерированный компилятором, программист не принимает участия в этом процессе. После того, как параметры занесены в стек, а процессор встречает инструкцию вызова функции, он заносит в стек некоторую информацию о текущем состоянии - как правило, это смещение следующей команды после команды вызова. Таким образом, функция, завершив свою работу, будет знать адрес возврата управления. В результате, во время выполнения первой строки функции стек имеет следующий вид:
Далее функции надо запомнить указатель на текущую верхушку стека (ВР), который будет использоваться в ссылке на параметры. Поэтому независимо от архитектуры выполняются следующие две инструкции:
|
|
|
push bp
mov bp, sp
Теперь в верхушке стека лежит предыдущее значение регистра ВР, а сам он указывает на верхушку стека и может быть использован в качестве базового регистра при ссылке на параметры.
В программе был объявлен размер буфера в 256 байт. Поскольку не использовались функции malloc() или new для выделения требуемого объема памяти, и не указывался модификатор "static", этот буфер будет зарезервирован в стеке. После всех этих операций стек примет следующий вид:
Программа работает нормально, пока не осуществляется вызов функции "strcpy()". Если длина строки меньше или равна длине буфера, то функция отработает, освободит зарезервированное пространство, восстановит регистр ВР, и, наконец, вернет управление программе, которая очистит стек от переданных параметров. Если длина строки будет больше размера буфера, то поскольку strcpy() копирует все символы, пока не встретит код конца строки - "О", часть строки затрет верхнюю часть стека и, естественно, может испортить поле RETADR. Это станет заметно не сразу, а после вызова returr(). Управление будет передано по адресу, который хранится в поле RETADR, но поскольку адрес испорчен, программа будет продолжать выполняться в некой точке адресного пространства, отличающейся от точки вызова. В этом месте и возникнет исключительная ситуация, и программа будет аварийно прервана, поскольку маловероятно, чтобы адрес возврата указывал на какой-то осмысленной код, причем находящийся в области памяти данной программы.
Такое оказывается возможным, если кто-то специально хотел вызвать подобную ситуацию. В качестве аргумента функции передается строка специально подобранной длины, так, чтобы она содержала некоторый машинный код, причем при затирании верхушки стека в поле RETADR попадал адрес именно этого кода.
|
|
|
После отработки функции return() управление получит новый фрагмент, что совсем не предусматривалось автором программы. Этот фрагмент и сможет выполнить произвольную операцию, обращаясь к сервису операционной системы.
Стек после вызова strcpy() будет иметь следующий вид:
Создается такой машинный код поэтапно. Во-первых, стоит выяснить примерный адрес верхушки стека на данном ПК при вызове функций, чтобы корректно сформировать адрес возврата, который попадет в поле RETADR. Как правило, это делается программой exploit с помощью вызова пустой функции, возвращающей в качестве параметра значение верхушки стека. Во-вторых, фрагмент должен быть написан таким образом, чтобы не содержать символа "О", который будет расценен как конец строки -этим символом код будет заканчиваться. При копировании он попадет в область параметров, но главное - управление будет передано на чужеродный фрагмент. В-третьих, точно должны быть рассчитаны размеры буфера, чтобы все попало в нужные места и не вызвало состояния core dump, должны быть учтены размеры других переменных, стоящих между буфером и RETADR. И, наконец, в-четвертых - взломщик должен уметь вызывать функции ОС.
Например, подобный код для Linux, BSD-family, а также ОС Solaris, вызывающий /bin/sh и легко подстраиваемый под конкретные размеры буфера, часто встречается в Internet и может быть использован для обнаружения новой "дырки" в программах.
Насколько реальна такая опасность? Программа не обращается к системным ресурсам. К стеку обращается программа пользователя, причем не к системному стеку, а к своему. Кроме того, нужно еще поискать ОС, которая проверяет, затирает ли записываемая в стек строка его верхушку. Это дело программиста и/или компилятора. На уровне ОС это невозможно детектировать, так как нарушения защиты не происходит - программа не выходит за пределы стека или сегмента.
Таким образом, метод работает везде, где:
• есть стек;
• имеется возможность вызвать систему через некий system call;
• адрес возврата из процедуры кладется в стек;
• локальные переменные размещаются в стеке;
• возможно выполнение кода, находящегося в стеке;
• существуют программы, выполняемые в режиме суперпользователя, доступные обычному пользователю и/или демоны, содержащие ошибки.
|
|
|
Как известно, этим требованиям удовлетворяют практически все операционные системы - именно поэтому проблема является столь глобальной.
Еще ряд примеров подобного вида атак. В программе rdist из BSD в одном из вызовов отсутствовала проверка на размер параметра, передаваемого из командной строки. Существует программа, которая формирует требуемый код и вызывает /usr/bin/rdist, передавая код в качестве параметра. Поскольку rdist выполняется с привилегиями суперпользователя (setuid bit), переданный код также выполнялся с привилегиями root и в распоряжении взломщика оказывался shell с правами root.
В одной из версий POP-сервера проверка длины строки присутствовала, но не была до конца корректной - не отлавливалось переполнение при вызове sprintf(). Была написана программа взлома, которая соединялась с 110-м портом (рор3-сервис) и передавала ему сформированный код, после чего pop-сервер сообщал о неверной команде sprintf() и "вываливался" в shell после return(), причем с правами суперпользователя root. В таком случае взломщику не требовалось даже Иметь свой раздел на ПК. Вирус Морриса использовал аналогичную неточность в широко распространенной программе finger.
Программы, написанные под X Window, как правило, передают параметр "-display <displayname>" на обработку Х-библиотеке. В XFree86 размеры displayname не проверяются и код для получения root-привилегий доступен через /usr/XllR6/bin/xterm. Но еще хуже, что код Xlib используется практически во всех Х-программах.
Недавно в списке рассылки freebsd-security была опубликована информация об ошибке - отсутствии проверки размера буфера - в подсистеме печати, являющейся фактическим стандартом и использующейся во всех семействах BSD, SunOS, а также входящей в состав остальных операционных систем (для совместимости). Эта ошибка может вызвать много проблем до ее исправления.
Также в последнее время примеры exploit-кода стали широкодоступны, и часто человеку (даже не системному программисту), заметившему неточность в программе, достаточно подкорректировать лишь несколько переменных (типа BUFFER_SIZE, SKIP_VARS), чтобы получить работающую программу-бандита.
|
|
|
Можно предложить два варианта защиты от ошибок класса buffer-overflow exploits.
Вариант первый - если доступны исходные тексты: в программах, выполняющихся с привилегиями суперпользователя (root setuid-программы; программы, вызывающиеся из inetd и т.д.), надо отыскать все вызовы функций strcpy, gets, sprintf, а, возможно, и других функций работы со строками, и проверить, не используются ли при этом локальные буферы фиксированной длины. Можно еще поискать константы типа BUFSIZ, РАТН_МАХ и др. Проанализировав текст, рекомендуется выполнить следующие действия:
• добавить проверки на длину строки;
• заменить strcpy, gets, sprintf etc на их аналоги для фиксированной длины - strncpy, snprintf, fgets;
• вместо фиксированных буферов использовать динамическое выделение памяти.
В качестве примера ошибочной программы можно привести rdist из BSD:
Проблема в том, что в but" фактически заносится аргумент из командной строки, длина которого не проверяется. Для исправления ситуации достаточно после строки, помеченной знаком "!!!", добавить следующий небольшой фрагмент (вместо printf полезно добавить запись в файл отчета информации о происшедшем с указанием имени пользователя, вызвавшего rdist):
Вариант второй - исходных текстов нет: необходимо написать сценарий, который пытается вызвать проверяемую программу, используя различные параметры достаточно большой длины. Например, строка для проверки команды xterm может выглядеть как:
В качестве параметра формируется строка длиной в 5000 символов (как показывает практика, программисты часто используют константы BUFSIZ, FILENAME_MAX и т.д., определенные в /usr/include, а они обычно не превышают 2048 байт). Изменяя число в строке и/или анализируя исходные тексты, можно уточнить размер буфера в программе. Если результатом выполнения этой команды будет фраза типа "Memory fault, core dump saved", то это означает, что имеется достаточно причин, чтобы:
• снять seiuid-бит с программы или запретить ее выполнение всем, кроме суперпользователя или ограниченной группы доверенных лиц;
• найти автора программы;
• попытаться самостоятельно исправить программу.
Часто трудно избежать полного анализа, текста программы, ведь никто не мешает автору использовать следующую конструкцию:
А результат получится тот же, как если бы воспользоваться стандартной функцией strcpy(). Кроме этого, метод передачи exploit-кода в программу может быть достаточно сложным. Например, для того чтобы воспользоваться "дыркой" в sendmail версии ниже, чем 8.7.5, код передается в GECOS-поле, которое в семействе ОС BSD пользователь может менять с помощью программ chfn, chsh и chpass.
|
|
|
Пример реальной программы, реализующий описанные выше возможности по получению root-привилегий, таков:
2.7. Использование слабостей технологий Java и ActiveX
Технологии Java фирмы SUN и ее конкуренту ActiveX компании Microsoft существуют недавно. Тем не менее эти технологии все чаще используются в интрасетях, уже заняли прочное место в арсенале Web-приложений и продолжают стремительно набирать темпы своего развития. Java проектировался как безопасный (с запрещением потенциально опасных функций), платформо-независимый, интерпретируемый язык программирования. Программный код небольших Java-приложений, называемых апплетами, находится на Web-сервере, в то время как на ПК клиента, просматривающего Web-сервер, находится интерпретатор команд, обычно встроенный в браузер. В HTML-разметке просматриваемой страницы имеется ссылка на программный код, который клиент загружает в свой ПК и исполняет при помощи встроенного интерпретатора. Примерно также работает технология ActiveX, за исключением того, что Java является сильно урезанным, интерпретируемым диалектом С++, а элементы ActiveX программируются, например, на Visual Basic. Кроме того, ActiveX поддерживает OLE (Object Linking and Embedding). Компания Microsoft так же, как и SUN, декларировала безопасность своей технологии. Однако, несмотря на изначально декларируемую безопасность, рассматриваемые технологии содержат в себе целый ряд дефектов, которые позволяют злоумышленникам осуществлять злонамеренные действия.
Наиболее серьезным недостатком обеих технологий является тот факт, что Java и ActiveX существуют как "безопасные" языки только в рамках компиляторов известных производителей ПО. Даже если кому-нибудь удастся создать действительно безопасный интерпретируемый язык и продавать его компилятор Web-дизайнерам, кто мешает злоумышленнику написать собственную версию компилятора, включив в нее все необходимые для его преступных замыслов системные функции? Скомпилировав на нем собственные апплеты, злоумышленник поместит их на свой собственный Web-сервер, а ПК-клиент послушно исполнит злонамеренный код, даже ничего не заметив. Таким образом можно получить практически полный контроль над ПК клиента. Представители фирм SUN и Microsoft, зная об этой проблеме, заявляли, что планируется оснащать компиляторы легальных производителей функциями, обеспечивающими зашивание сигнатуры производителя в интерпретируемый код, по которому программа-браузер сможет опознать производителя компилятора и принять решение о запуске апплета. Однако вопрос о том, можно ли будет обойти эти соглашения, повисает в воздухе из-за отсутствия реализации соглашений.
Конкретный пример НСД на основе использования слабостей технологии ActiveX таков - организация хакеров Computer Chaos Club продемонстрировала созданный ими ActiveX-компонент, способный незаметно загружаться в клиентский ПК во время просмотра им Web-страниц с использованием MS Internet Explorer 3.1 [32]. Данный компонент запускается автоматически и может переводить деньги на счета злоумышленников со счета любого клиента, использующего финансовую программу Quicken фирмы Intuit для "электронной" оплаты своих счетов.
И еще один случай: программист из Сиэттла поместил в сеть программу, названную Exploder, которая отключала от Internet ПК, когда пользователи Internet Explorer пытались загрузить Web-страницу.
Взломщиков технология ActiveX привлекает значительно больше, чем Java компании Sun Microsystems, так как компоненты ActiveX имеют прямой доступ к операционным системам, a Java-апплеты - нет. Это предоставляет ActiveX значительно больше возможностей и для созидания, и для разрушения: можно переформатировать жесткий диск ПК или включить систему видеонаблюдения.
Серьезные проблемы с безопасностью информации возникают также из-за такой особенности ActiveX, как поддержка OLE. При этом становится возможным просматривать документы, хранящиеся на Web-сервере, в том формате, в котором они были созданы, например, просматривать, не загружая документы Word, таблицы Excel или презентации PowerPoint. Таким образом, можно даже не подозревать, что при просмотре на экране текстового документа, существует опасность занесения в ПК злонамеренной резидентной программы. Сценарий таков: с помощью текстового процессора Word просматривается документ, лежащий на Web-сервере и содержащий макровирус. Текстовый процессор исполняет макрокод, содержащийся в документе, и согласно его инструкциям заражает вирусом все документы Word, имеющиеся на жестком диске, и запускает стандартный отладчик Microsoft - debug.com, который имеется в любой системе. С помощью debug.com макровирус записывает злонамеренную, резидентную часть в оперативную память и заканчивает программу. Описанный выше сценарий вполне правдоподобен, так как технология ActiveX уже работает на тысячах браузеров, а макровирус Word с резидентной частью был описан еще три года назад.
Все эти методы осуществления угроз безопасности информации имеют одно свойство: для их применения необходимо, чтобы пользователь компьютера-цели сам зашел на Web-сервер злоумышленника. Однако это не значит, что следует преуменьшать существующую угрозу в случае, если пользователь работает только с жестко определенным, проверенным набором серверов. Злоумышленник может применить вышеперечисленные методы в сочетании с подменой доменных имен. Смоделировав на собственном подставном сервере привычную для пользователя оболочку и внедрив в нее злонамеренные апплеты, злоумышленник достигнет своей цели, не вызвав никаких подозрений.
Наиболее уязвимыми с точки зрения безопасности компонентами Java-технологии являются апплеты, поскольку их может использовать любой клиент, который вовсе не обязан знать правила "техники безопасности" при работе с ними. Именно поэтому для апплетов предусмотрены жесткие методы защиты [33]. Хотя различные браузеры и программы просмотра апплетов могут по-разному защищать информацию пользователя от нападения, но в общем случае апплету должно быть запрещено следующее:
• читать, изменять, уничтожать и переименовывать локальные файлы;
• создавать локальные директории и читать их содержимое;
• проверять существование и параметры определенного файла;
• осуществлять доступ по сети к удаленному компьютеру (кроме своего "родного" узла);
• получать список сетевых сеансов связи, которые устанавливает локальный компьютер с другими компьютерами;
• открывать новые окна без уведомления пользователя (это необходимо для предотвращения "эмуляции" апплетом других программ);
• получать сведения о пользователе или его домашней директории;
• определять свои системные переменные;
• запускать локальные программы;
• выходить из интерпретатора Java;
• загружать локальные библиотеки;
• создавать потоки, которые не перечислены в ThreadGroup (класс, управляющий выполнением потоков - различных частей программы) этого апплета, и управлять ими;
• получать доступ к ThreadCroup другого апплета;
• определять свои объекты Class-Loader (загрузчик Java-объектов) и Stcurity Manager (диспетчер безопасности для апплетов);
• переобозначать системные объекты ContentHandlerFactory, SocketlmplFactory и URLStreamHandler-Factory (эти классы управляют сетевой работой Java);
• получать доступ к любому пакету, отличному от стандартных;
• определять классы, которые входят в локальную упаковку. Эти правила обеспечивают следующие компоненты Java-технологии.
1). Собственно виртуальный Java-процессор, который постоянно контролирует свое состояние.
2). Загрузчик апплетов и Java-программ, который контролирует загружаемые коды.
3). Диспетчер безопасности (SecurityManager), контролирующий и блокирующий опасные действия апплетов.
В классе SecurityManager перечислены методы, которые используются системой для контроля действий апплета в зависимости от характеристик окружающей среды. Программа просмотра апплета создает подкласс SecurityManager, который и реализует необходимую политику безопасности. Ссылка на этот SecurityManager записывается в объекте System.
Еще один механизм безопасности встроен в загрузчик апплетов и программ (ClassLoader). Браузер переопределяет этот класс и реализует свои собственные правила работы с сетевыми протоколами. Одна из основных функций загрузчика объектов - разделение пространства имен разных апплетов и операционной системы, что позволяет избежать их взаимного влияния. Другая, не менее важная, функция загрузчика - верификация байт-кодов, т.е. проверка правильности полученного элемента Java-программы и его целостности. В процессе верификации выясняется следующее:
• соответствует ли версия полученного блока версиям остальных элементов системы;
• сохранен ли формат исполняемого байт-кода;
• соответствует ли программа спецификации конкретного виртуального Java-процессора;
• может ли возникнуть переполнение или исчерпание стека;
• все ли регистры Java-процессора используются правильно;
• нет ли некорректных преобразований типов.
Цели такой проверки - выявление неправильного использования косвенной адресации, которое может привести к нарушению в работе виртуального процессора, и проверка целостности апплета. Этот механизм обеспечивает защиту и надежную работу распределенной программы, что позволяет не загружать в браузер всю Java-программу целиком, а подгружать ее небольшими блоками по мере необходимости.
Сам виртуальный Java-процессор также имеет встроенные механизмы защиты от нападения. Например, поскольку байт-коды Java интерпретируются, то можно контролировать индексы массивов, что позволяет избежать переполнение буфера - самой распространенной и опасной ошибки. Встроенные механизмы обработки исключительных ситуаций позволяют решать возникающие конфликты, а "сборщик мусора", который очищает неиспользуемую память, не дает возможности взломщику просмотреть "отходы", которые могут содержать полезную информацию.
Хотя защитные механизмы технологии Java очень хорошо продуманы, их реализация еще далека от совершенства. Список возможных нападений таков.
1. Блокировка сервиса. Это нападение, в результате которого частично или полностью блокируется работа пользователя и даже может быть выведен из строя браузер. Вот не полный список возможных вариантов:
• загрузка процессора бессмысленными действиями (например, бесконечным циклом);
• заполнение всей свободной памяти (например, в результате выполнения бесконечного цикла);
• захват важных системных классов, например java.net-INetAddress.
2. "Тайные" каналы. Эти каналы позволяют взломщику получать информацию даже через МЭ. Существование "тайных" каналов в браузере делает его опасным. В качестве "тайного" канала можно использовать следующие действия апплетов:
• посылку почты через SMTP-порт сервера (причем почта посылается от имени пользователя, который работает с апплетом);
• запрос на поиск по несуществующему адресу, в котором в качестве параметров передаются необходимые "взломщику" данные;
• попытку доступа по несуществующему адресу (последовательность директорий может содержать необходимые данные).
3. Информация, известная апплетам. С помощью этой информации взломщик может получить некоторые сведения, которые впоследствии могут быть им использованы. Эту информацию можно передавать даже через МЭ по тайным каналам, которые описаны выше. Апплетам обычно известна следующая системная информация:
• системное время;
• установки функции hashcode();
• название и производитель Java-интерпретатора;
• версия JavaAPI;
• название и версия операционной системы;
• архитектура процессора.
4. Ошибки реализации. Это основной способ нападения. Ошибки обычно трудно находить и исправлять. Причем для исследования пользовательской системы можно применять информацию, которая доступна апплетам. Например, если взломщик знает, что в определенной версии Internet Explorer есть "полезная" для него ошибка, то, считывая с помощью апплета название и версию браузера и передавая эту информацию по тайным каналам (запрос по несуществующему адресу), он получает информацию о своей "жертве".
5. Перехват ошибок. Java предусматривает перехват исключительных ситуаций. Это необходимо для составления более наглядных программ, благодаря которым обработку всех ошибок можно выполнять централизовано. Однако перехват ошибок позволяет ипгнорировать исключительные ситуации, создаваемые, например, SecurityManager. Такая ситуация очень опасна, так как позволяет взломщику заменит» ClassLoader, SecurityManagcr и другие ключевые объекты. Желательно было бы блокировать подобные ситуации еще при загрузке апплета, но современные загрузчики этого не умеют.
6. Имя упаковки. Если "/" - первый символ имени упаковки, то система попытается загрузить эту упаковку с локального диска, причем загружается она с меньшими требованиями к безопасности, так как предполагается, что запускаемому с локального диска апплету можно доверять. Таким образом, любой Java-класс, который взломщик может записать на локальный диск, может быть загружен с ослабленной защитой. Причем "опасные" классы могут быть записаны на диск с помощью механизма кэширования браузера. Поэтому становится возможной загрузка "агрессивного" класса с ослабленной защитой.
Проблема безопасности обсуждаемых технологий не исчерпывается проблемой неавторизованного компилятора. Ниже представлены некоторые возможные злонамеренные апплеты, запрограммированные на основе серийных, "безопасных" компиляторов: (Большинство примеров взято с сервера http://www.digicrime.com/, где можно попробовать их в действии.)
1. Достаточно просто написать апплет, создающий серии самовоспроизводящихся окон. Родительское окно запускает дочернее, то в свою очередь - следующее и так далее до переполнения оперативной памяти клиентского ПК. Результатом переполнения, в лучшем случае, является выгрузка программы-браузера.
2. Усовершенствованный вариант примера 1. Апплет вызывает не последовательность самовоспроизводящихся окон, а последовательность самовоспроизводящихся браузеров (браузеры фирм Netscape и Microsoft имеют функцию "создать новый браузер"). Результатом, как правило, является сбой в ОС клиента.
3. Апплет, вызывающий зацикленное переключение между двумя Web-страницами, не нарушает, казалось бы, никаких принципов безопасности информации. Однако он заставляет пользователя в аварийном режиме выгрузить браузер, и тем самым, может быть, потерять ценные данные.
4. Не составляет большого труда, запрограммировать апплет на скачивание необходимого злоумышленнику файла с клиентского компьютера. При этом, правда, большинство браузеров выдадут предупреждение с запросом на разрешение выполняемых действий, но эта опция может быть отключена, да и пользователь, привыкший к путешествиям по Internet, может "щелкнуть" ОК.
5. Существует апплет, пользующийся функциями системы энергосбережения "Energy saving future" для несанкционированного выключения компьютера клиента, оснащенного этой системой, из сети электропитания (http://catless.ncl.ac.uk/Risk/18.61.html).
6. Существует апплет, вызывающий фатальное зависание ОС Windows 95 при его запуске (http://www.digicrime.com/).
Для обеспечения безопасности информации при корпоративном доступе в Internet необходимо отключать на всех клиентских ПК модули поддержки Java и ActiveX. Использование этих модулей может быть целесообразным только в случае отдельного компьютера, подключенного к Internet и управляемого квалифицированным пользователем.
Методы обеспечения безопасности управляющих элементов ActiveX на рабочих столах пользователей включают в себя подпись HTML, серверы-посредники и усовершенствованные МЭ, а также создание и использование баз данных, содержащих информацию о статусе безопасности различных апплетов Java [34]. В случае применения метода подписи HTML, управляющие элементы ActiveX или апплеты Java работают на пользовательском ПК только при условии, что страница HTML, содержащая управляющий элемент, открыта браузером пользователя. Модель подписи HTML дает пользователю возможность точно определить в процессе выполнения, когда и откуда поступил данный фрагмент исполняемого кода. Серверы полномочий (proxy) и усовершенствованные МЭ позволяют системным администраторам создавать базы данных дружественных и враждебных апплетов, а также управляющих элементов. Данная технология использует для сканирования с целью определения входящего трафика те же принципы, что и базы данных вирусов. Также возможно включение в корпоративную базу данных информации о санкционировании выполнения определенных апплетов Java для конкретных компьютеров. Эта информация проверяется перед запуском апплета на данном компьютере. Можно воспользоваться и встроенными средствами защиты браузера Internet Explorer, задающими три уровня защиты.
Защита в ActiveX осуществляется и программой Authenticode корпорации Microsoft через средства, встроенные в управляющий элемент ActiveX и сообщающие пользователю, кто создал данный элемент, и проверяющие его подлинность. Идентификаторы задаются в Authenticode с помощью цифровых подписей и сертификатов. Цифровой сертификат предоставляет информацию о разработчике (его имя и адрес электронной почты), а цифровая подпись представляет собой уникальный набор его описателей (хэш-функция, зашифрованная личным ключом).
В Java для обеспечения безопасности также используется так называемая "песочница" (sandbox) – среда, в которой код, пришедший из Internet, исполняется практически без доступа к локальным ресурсам. В Java Development Toolkit безопасность обеспечивается на базе доменов – среды или контекста приложения, для которого определен собственный набор допущений и требований. Также проверяется наличие "дыр" на пересечении привилегий, действующих в различных доменах.
|
|
|
