CC BY
96
192(256-64), поскольку необходимо резервировать память для записи 64-битного поля инструкций процессора. Мы эмулируем полностью вызов функции call ebx[esp] на уровне Р-кода. Список структур EPROCESS (исполнительное пространство процессов) всех процессов в системе начинается с переменной ядра PsActiveProcessesLink, которая ядром не экспортируется, но ее можно получить с помощью анализа двухсвязного списка структур EPROCESS. Для получения списка всех процессов в системе нужно реализовать алгоритм сканирования PsCid-таблиц, минуя стандартные интерфейсные вызовы, получить указатель на EPROCESS любого процесса, после чего двигаться по спискам ActiveProcessesLink до той структуры, с которой начали. В качестве эталона необходимо получить указатель на EPROCESS процесса System, так как это единственный обязательный процесс в системе, который существует все время ее работы (после загрузки). Для получения этого указателя сначала получим с помощью функции ядра IoGetCurrentProcess указатель на EPROCESS текущего процесса, после чего будем двигаться по связанным спискам, просматривая содержимое структуры PsContext, пока не обнаружится процесс с Pid=0 и со значением бита подчинения 0rd=0 (родительский процесс) - это и будет процесс System. В ходе экспериментов были выявлены недокументированные структуры внутренних дескрипторных таблиц ядра Windows, которые позволяют эффективно обнаруживать базовые процессы-потоки во взаимодействии с низкоуровневыми микрообъектами. Процессор разрешает об-
ращаться к внутренним структурам через указатель &Context, поскольку во время операции теневого копирования блокируется доступ к внутренним регистрам программными средствами. Внедрившись в системный стек, автор получил прямой доступ к Context ID процессов ядра посредством оригинального метода. Теперь краткий фрагмент кода поиска EPROCESS процесса System выглядит так:
UndocData: packed record // описание недокументированной внутренней структуры планировщика процессов ядра
{Получение списка процессов прямым доступом к структурам ядра.
{получение указателя на структуру EPROCESS для System }
function GetSystemEPROCESS(): dword; Data.UndocAdr := @UndocData; // декларация недокументированных структур ps-таблиц ядра
CallRing0(@Ring0Call, @Data);// вызов функции перехвата полного контекста
Offset=01B0 (данное смещение позволяет получить доступ к контексту TSS-регистра)
(*(PUSH0RT)p0pcode==0x01B1 &&*(p0pcode+2)==0xE8) CurrentStruct:=pdword(dword(@Eprocess)+UndocData.Acti vePsList0ffset)A;// указатель на полный список активного контекста процессов ядра}.
В заключение отметим, что материалы проведенных исследований использованы при создании средства защиты информации ViPNet Office Firewall компании «ИнфоТеКС» (г. Москва). Эффективность полученных результатов подтверждена документально. Уникальность предложенных автором методов заключается в том, что реализованные алгоритмы сканируют списки процессов и потоков посредством чтения данных из внутренних недокументированных структур микроядра.
ИССЛЕДОВАНИЕ ПРОЕКТОВ ВЕРХНЕГО И НИЖНЕГО УРОВНЕЙ ПОЛИТИКИ БЕЗОПАСНОСТИ ОС WINDOWS
А.А. Грушо, д.ф.-м.н.; А.С. Моляков
(Институт информационных наук и технологий безопасности, г. Москва)
Применяемые в системах обработки информации организационные меры защиты не могут обеспечить необходимую степень безопасности заинтересованных субъектов информационных отношений. Достаточно сказать, что наиболее популярная MS DOS является полностью открытой системой и не имеет никаких механизмов защиты. Защитные функции среды Windows 3.X, Windows 95 (далее Windows) весьма ограничены. Наиболее широко распространенная сетевая операционная система (ОС) Novell Netware, хотя и имеет богатый арсенал механизмов защиты, но все они предназначены для защиты данных, хранимых на сетевых дисках (на файловых серверах). Именно поэтому исследование формальных моделей безопасности становится определяющей задачей.
Цель работы - выявить неопределенности (коллизии) в формальном описании политики безопасности (ПБ) Windows NT и продемонстрировать несоответствие ее требованиям полноты и непротиворечивости. Рассмотрим общие положения исследования проектов верхнего и нижнего уровней ОС класса NT.
Описание исследования формальной модели ПБ Windows NT 5.1
Групповые ПБ (Group Policy - GP) представляют собой основной метод обеспечения централизованного управления конфигурацией безопасности в Windows XP и Windows 2003. Они могут применяться на уровне сайта, домена и OU, а также могут применяться к пользователям и компью-
терам (Users and Computers) в Adive Directory. GP используются для выполнения следующих действий: блокировка рабочих столов пользователей; применение параметров безопасности; ограничение доступа к приложениям; установка разрешения реестра и файловой системы.
Область настройки пользователя User Configuration содержит такие элементы, как параметры рабочего стола, параметры безопасности и сценарии входа и выхода их системы. Эти элементы определены под деревом User Configuration и применяются при входе в систему или обновлении GP. Computer Configuration используется для настройки работающей системной среды (а не пользовательской оболочки), включая параметры служб, параметры безопасности и сценарии загрузки/отключения. Эти элементы определены в дереве Computer Configuration и применяются при загрузке и обновлении GP. По умолчанию GP применяются в зависимости от расположения настраиваемого объекта. Пользовательские GP зависят от того, в каком сайте, домене и организационной единице находится объект "пользователь". То же самое относится и к компьютеру. GP применяются к компьютерам в зависимости от расположения объекта "компьютер" (сайт, домен и организационная единица, в которой находится компьютер). Это означает, что если GP применяется к объекту User (пользователь), то используется конфигурация пользователя, а конфигурация компьютера GP игнорируется. И наоборот, если GP применяется к объекту Computer (компьютер), используется конфигурация компьютера, а конфигурация пользователя игнорируется. Имеются две GP, установленные по умолчанию, используемые при создании домена: Default Domain Policy (политика домена по умолчанию) и Default Domain Controller Policy (политика контроллера домена). Приведем общее описание спецификаций проектов верхнего и нижнего уровней.
Верхний уровень спецификации включает в себя модули защиты контроллера (ActiveDirectory), менеджера сессии, исполнительной подсистемы клиентских динамических библиотек сгss.exe, исполнительной подсистемы Win32, менеджера файловой системы. Идентификаторы системы безопасности на HLP (High Level Project) с реализацией шаблонов GP включают в себя описание объектов и субъектов доступа.
Объекты Windows.
Session Objects - метка доступа (Security Token). Реализованы функции аутентификации-идентификации и поддержки контекста безопасности процессов (потоков) Security Policy Manager (идентификатор sid).
File Objects - идентификатор процесса, создаваемого при загрузке файла в оперативную память (в режиме исполнения, чтения или записи) Pid (Process Id). Данный уровень реализует функции
защиты менеджера виртуальной памяти и файлового менеджера, работу с идентификаторами пользователей и группы пользователей (uid и guid).
Symbol Link - ссылки на девайс-устройства в пространстве пользовательских процессов, логические диски пользователей в глобальной сессии или определенная для конкретного локального окружения безопасности ссылка на ресурс {Sym Link ?? \\ путь к устройству}.
На данном уровне реализованы функции диспетчера объектов Windows.
Кодирование прав доступа к объектам Windows описывается в виде RWE-структуры, где R -право на чтение, W - право на запись, E - право на исполнение. В ОС класса NT существуют четыре группы безопасности: группа администраторов, пользователи, гости и специальная учетная запись для владельца System_Authority. Все субъекты, входящие в группу администраторов, получают права Admin. В заданной GP явного присвоения значений полю учетной записи владельца Sys-tem_Authority не происходит. Все необходимые данные для монитора безопасности при инициализации прав доступа по умолчанию наследуются от группы администраторов.
Неопределенность настройки шаблонов безопасности, совмещение прав Admin и System_ Authority создает угрозу неконтролируемого повышения полномочий приложения на уровне супервизора системы. По умолчанию все настройки для группы администраторов наследуются для создаваемых экземпляров системных объектов, отсутствует контроль явной инициализации бита s (бит системности), его заменяет поле control структуры SE_Privikge.
Промежуточный уровень спецификации включает модули защиты менеджера ввода-вывода нижнего уровня и верхнего слоя исполнительной среды ядра. На данном этапе реализованы функции контроля исполнения кодов на уровне вызова Runtime-библиотек загрузчика Windows, обработка исключений, взаимодействие клиентских приложений с системным обработчиком де-скрипторных таблиц ядра NT. Мы оперируем со структурой атрибутов доступа и используем расширение представления примитивов безопасности (проверку привилегий на нижнем уровне операций ввода-вывода). Главный признак - проверка полномочий на запуск.
На рисунке приведены неявные связи в схеме «субъект-объект доступа». В заданной ПБ существуют состояния с повышением уровня полномочий (субъект может запускать процесс в контексте безопасности другого пользователя), существуют неоднозначные связи между графами состояний процессов. Поскольку на верхнем уровне нет явного контроля работы с экземплярами системных объектов с инициализацией бита s, то запущенные процессы (потоки) могут внедряться в простран-
Неоднозначность связей в схеме «субъет-объект доступа»
(СРЬ - текущий уровень привилегий пользователей (субъектов); ЭРЬ - уровень привилегий на доступ к данным (ресурсам-объектам); ЕРЬ - запрашиваемый уровень привилегий (делегирование полномочий))
ванной обработки процессов-потоков при взаимодействии с объектами ядра на уровне драйверов. Ссылки и описатели на устройства в пространстве пользователей отличаются от ссылок на ресурсы ядра (\\SymLink и \\Device ), то есть существует неопределенность описания состояний в заданной ПБ. Кроме того, на уровне микроядра право на запуск представляется двухбитным полем - битом подчиненности, который определяет родительский или дочерний процесс (поток) и создается в системе, и значением ContextId, которое идентифицирует запущенный процесс (поток) в списке внутренних таблиц процессора.
В ходе исследования формальной модели безопасности ОС Windows NT 5.1 были получены следующие научные результаты.
Существует понятие противоречивости правил безопасности ОС Windows, позволяющее получать несанкционированный доступ или вызывать сбои функционирования, изменять, модифицировать и нарушать правила действующей ПБ.
Иерархическое описание ссылок (дескрипторов) при следовании сверху-вниз от проекта верхнего уровня до проекта нижнего уровня модифицируется, дополняется новыми дескриптивными атрибутами модели ПБ, благодаря чему допускается ее неоднозначное толкование.
Неполнота правил ПБ, неоднозначность трактовки заданных формальных шаблонов ПБ приводит к возникновению уязвимостей - условий, нарушающих стабильность и реентрантность работы ОС в целом. Угроза нарушения доступа к конфиденциальной информации обусловливает необходимость разработки новых методов поиска скрытых процессов ядра Windows NT 5.1.
Задание ПБ на верхнем уровне не соответствует требованиям безопасности на нижнем уровне, что подтверждает несостоятельность и неполноту ПБ. Формальное задание ПБ не является полным и непротиворечивым.
Научное обоснование неполноты выполнения требований по безопасности получило подтверждение как в виде формального анализа и описания спецификаций на верхнем и нижнем уровнях, так и определило необходимость реализации эффективных оригинальных алгоритмов поиска уяз-вимостей на уровне объектов микроядра (самый низкоуровневый слой ядра Windows).
ство «чужого» процесса и получать управление, более того, несанкционированно модифицировать, изменять и нарушать правила доступа к защищенным ресурсам ОС и данным пользователей. Когда менеджер ввода-вывода помещает данные актива-ционной записи в стек и вызывает команду на повышение привилегий с целью проверки, возможно внедрение в системное пространство или атака с целью переполнения буфера (отказ системы).
Нижний уровень спецификации включает модули защиты HAL-среды, уровень драйверов физических, логических и виртуальных устройств, диспетчера ввода-вывода системных запросов. На данном уровне идет работа с циклом обработки IRP-пакетов, вместо прав владельца используется файл конфигурации для устройств с расширением INF (где указывается владелец, время и дата создания, текущие настройки). На этом уровне уже не действуют механизмы защиты монитора безопасности. Загрузка кода идет в системное пространство путем прямого вызова системной функции диспетчера Driver _Entry. Диспетчер объектов памяти считывает значения раздела \\Service, UNICODE - строку имени устройства \\DEVICE, получает указатель на объект драйвера, создает линк (привязку) к конкретному устройству с CLSID в корневом разделе реестра. Более того, загрузка драйвера и его идентификация в памяти осуществляются путем разыменования указателя на область памяти и чтения PE-заголовка загруженного образа модуля sys (создается имя объекта DDO - Driver Definition Object, которое и используется для аллокации объектов в оперативной памяти). На уровне драйвера отсутствует эффективный механизм защиты. Примитивы монитора безопасности не реализованы на уровне HAL-диспетчера. Не разработан метод инкапсулиро-
ОБЕСПЕЧЕНИЕ САМООРГАНИЗАЦИИ ЕДИНОГО ИНФОРМАЦИОННОГО ПРОСТРАНСТВА ПРЕДПРИЯТИЯ
А.В. Иващенко, к.т.н. (Самарский государственный аэрокосмический университет)
Организация единого информационного пространства (ЕИП) предприятия является доста-
точно сложной задачей, связанной с необходимостью удовлетворения большого количества раз-
