Московский физико-технический институт
Опубликован: 12.12.2007 | Доступ: свободный | Студентов: 5497 / 1832 | Оценка: 4.34 / 4.14 | Длительность: 13:57:00
ISBN: 978-5-94774-827-7
Лекция 15:

Отдельные аспекты безопасности Windows

< Лекция 14 || Лекция 15: 123

Недопустимость повторного использования объектов

Согласно п.4 политики безопасности, ОС должна защищать объекты от повторного использования. Перед выделением новому пользователю все объекты, включая память и файлы, должны быть проинициализированы. Контроль повторного использования объекта предназначен для предотвращения попыток незаконного получения конфиденциальной информации, остатки которой могли сохраниться в некоторых объектах, ранее использовавшихся и освобожденных другим пользователем.

Безопасность повторного применения должна гарантироваться для областей оперативной памяти (в частности, для буферов с образами экрана, расшифрованными паролями и т.п.), для дисковых блоков и магнитных носителей в целом. Очистка должна производиться путем записи маскирующей информации в объект при его освобождении (перераспределении).

В ОС Windows гарантируется безопасность повторного использования областей физической памяти. Согласно [ Руссинович ] , если пользовательскому процессу понадобилась свободная страница памяти, она может быть выделена только из списка обнуленных страниц базы данных PFN (см. раздел, связанный с работой менеджера памяти). Если этот список пуст, страница берется из списка свободных страниц и заполняется нулями. Если и этот список пуст, диспетчер памяти извлекает страницу из списка простаивающих (standby) страниц и обнуляет ее. Необнуленная страница передается только для отображения проецируемого файла. В этом случае фрейм необнуленной страницы инициализируется данными с диска.

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

Защита от внешнего навязывания

В соответствии с политикой безопасности операционная система должна защищать себя от внешнего влияния или навязывания, такого, как модификация загруженной системы или системных файлов, хранимых на диске. Чтобы удовлетворить требованиям политики безопасности, в ОС Windows встроены средства защиты файлов (Windows File Protection, WFP), которые защищают системные файлы даже от изменений со стороны пользователя с административными правами. В основе защиты лежат средства фиксации изменений в системных файлах (см. "Реализация файловой системы. Файловая система NTFS" ). Данная мера, безусловно, повышает стабильность системы.

Согласно документации, мониторингу и защите подлежат все поставляемые в составе ОС файлы с расширениями sys, dll, exe и ocx, а также некоторые шрифты TrueType (Micros.ttf, Tahoma.ttf и Tahomabd.ttf). Если выясняется, что файл подменен, он заменяется копией из каталога %systemroot%\system32\dllcache, на который указывает одна из записей в реестре. Если размер места, выделенного для этого каталога, не достаточен, то в нем сохраняются копии не всех системных файлов. В тех случаях, когда делается попытка удаления системного файла и при этом его не оказывается в каталоге dllcache, система пытается восстановить его с установочного компакт-диска ОС Windows или из сетевых ресурсов.

Кроме того, администратор системы с помощью утилиты Sfc.exe (system file checker) может осуществить проверку корректности версии всех системных файлов. Сведения о файлах с некорректным номером версии заносятся в протокол. Корректность системных файлов проверяется с помощью механизма электронной подписи и к неподписанным файлам следует относиться с осторожностью. Для проверки подписи и выявления неподписанных файлов служит штатная утилита SigVerif.exe.

Задание. Попробуйте удалить какой-либо системный файл из каталога Windows\system32, например, sol.exe (игра "косынка").

Маркер доступа. Контекст пользователя

Как уже говорилось, наиболее важной характеристикой субъекта является маркер доступа. Обычно маркер создается при интерактивном входе пользователя в систему и хранит сведения о контексте пользователя. Вначале маркер связывается с процессом-оболочкой Windows Explorer, а затем все процессы, порожденные пользователем во время сеанса работы, получают дубликат данного маркера. Важно понимать, что самостоятельно создать маркер пользовательское приложение не может. Это может сделать только служба Lsass.

Ранее были рассмотрены характеристики маркера как одного из ключевых звеньев в системе контроля доступа. В настоящем разделе описаны возможности более тонкой настройки контекста пользователя при помощи функций, ориентированных на работу с маркером доступа в соответствии с принципом минимума привилегий. Принцип минимальных привилегий рекомендует выполнение всех операций с минимальными привилегиями, необходимыми для достижения результата. Это позволяет уменьшить потери от попыток намеренного ущерба и избежать случайных потерь данных. Например, пользователю не рекомендуется регистрироваться в качестве администратора системы без необходимости. (В крайнем случае, можно прибегнуть к услугам штатной утилиты runas, которая позволяет запускать приложения от имени другой учетной записи.)

Для безопасной работы в духе принципа минимума привилегий ОС Windows поддерживает механизмы создания маркеров с ограниченными привилегиями и заимствования маркера. Первый позволяет изъять из маркера определенные привилегии, наличие которых при выполнении данной операции не нужно, а второй разрешает запускать приложения от имени другой учетной записи. API системы позволяет влиять на перечень действующих привилегий маркера, дублировать маркер, чтобы его мог заимствовать другой процесс, решать проблемы перевоплощения и создания ограниченных маркеров

Считывание сведений о привилегиях пользователя из маркера доступа

В предыдущих лекциях описаны привилегии пользователя (раздел "ролевой доступ") и основные функции для считывания информации из маркера ( OpenProcessToken, GetTokenInformation ) в разделе "субъекты". Для получения списка привилегий из маркера при помощи функции GetTokenInformation нужно для параметра TokenInformationClass, выбрать значение TokenPrivileges. Ранее мы уже получали перечень привилегий учетной записи. Перечень привилегий, входящих в состав маркера, существенно шире, поскольку включает в себя привилегии пользователя и привилегии групп, в состав которых входит пользователь.

Прогон программы получения списка привилегий из маркера доступа процесса

В качестве примера рассмотрим программу, задача которой - получение перечня привилегий пользователя и его групп из маркера доступа данного процесса.

#include <windows.h>
#include <stdio.h>
#pragma hdrstop

void main()
{
 HANDLE hToken;
 LUID setcbnameValue;
 TOKEN_PRIVILEGES tkp;
 DWORD errcod;
 LPVOID lpMsgBuf;
 LPCTSTR msgptr;

 UCHAR InfoBuffer[1000];
 PTOKEN_PRIVILEGES ptgPrivileges = (PTOKEN_PRIVILEGES) InfoBuffer;
 DWORD dwInfoBufferSize;
 DWORD dwPrivilegeNameSize;
 DWORD dwDisplayNameSize;
 UCHAR ucPrivilegeName[500];
 UCHAR ucDisplayName[500];
 DWORD dwLangId;
 UINT i;

 if ( ! OpenProcessToken( GetCurrentProcess(),
  TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken ) )
 {
  puts( "OpenProcessToken" );
  return;
 }

 GetTokenInformation( hToken, TokenPrivileges, InfoBuffer,
  sizeof InfoBuffer, &dwInfoBufferSize);

 printf( "Account privileges: \n\n" );
 for( i = 0; i < ptgPrivileges->PrivilegeCount; i ++ )
 {
  dwPrivilegeNameSize = sizeof ucPrivilegeName;
  dwDisplayNameSize = sizeof ucDisplayName;
  LookupPrivilegeName( NULL, &ptgPrivileges->Privileges[i].Luid,
   (char *)ucPrivilegeName, &dwPrivilegeNameSize );
  LookupPrivilegeDisplayName( NULL, (char *)ucPrivilegeName,
   (char *)ucDisplayName, &dwDisplayNameSize, &dwLangId );
  printf( "%s   (%s)\n", ucPrivilegeName, ucDisplayName);
 }

}

Задача приведенной программы - получить описатель текущего процесса при помощи функции OpenProcessToken и применить функцию GetTokenInformation для извлечения из него списка привилегий. Функция LookupPrivilegeName позволяет получить программное имя привилегии по ее локальному идентификатору (Luid), а функция LookupPrivilegeDisplayName преобразует программное имя привилегии в дружественное имя.

< Лекция 14 || Лекция 15: 123
Ирина Оленина
Ирина Оленина
Николай Сергеев
Николай Сергеев

Здравствуйте! Интересует следующий момент. Как осуществляется контроль доступа по тому или иному адресу с точки зрения обработки процессом кода процесса. Насколько я понял, есть два способа: задание через атрибуты сегмента (чтение, запись, исполнение), либо через атрибуты PDE/PTE (чтение, запись). Но как следует из многочисленных источников, эти механизмы в ОС Windows почти не задействованы. Там ключевую роль играет менеджер памяти, задающий регионы, назначающий им атрибуты (PAGE_READWRITE, PAGE_READONLY, PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_NOACCESS, PAGE_GUARD: их гораздо больше, чем можно было бы задать для сегмента памяти) и контролирующий доступ к этим регионам. Непонятно, на каком этапе может включаться в работу этот менеджер памяти? Поскольку процессор может встретить инструкцию: записать такие данные по такому адресу (даже, если этот адрес относится к региону, выделенному менеджером памяти с атрибутом, например, PAGE_READONLY) и ничего не мешает ему это выполнить. Таким образом, менеджер памяти остается в стороне не участвует в процессе...