Файл: Debian Таненбаум Бос.pdf

1046  

 Глава 11. Изучение конкретных примеров: Windows 8 

11.10.2. Вызовы интерфейса прикладного 
программирования безопасности

Большая часть механизма управления доступом в Windows основана на дескрипторах 
безопасности. Обычно схема такая: когда процесс создает объект, он предоставляет 
дескриптор безопасности в качестве одного из параметров CreateProcess или CreateFile 
(либо другого вызова создания объекта). Этот дескриптор безопасности затем становится 
прикрепленным к объекту дескриптором безопасности (рис. 11.30). Если при вызове 
создания объекта не предоставлен дескриптор безопасности, то вместо него используется 
безопасность по умолчанию из маркера доступа вызывающей стороны (см. рис. 11.29).

Многие вызовы системы безопасности в Win32 относятся к управлению дескрипторами 
безопасности, поэтому мы сосредоточимся здесь именно на них. Самые важные вызовы 
перечислены в табл. 11.17. При создании дескриптора безопасности сначала под него 
выделяется, а затем и инициализируется (при помощи InitializeSecurityDescriptor) ме-
сто хранения. Этот вызов заполняет заголовок. Если SID владельца неизвестен, то его 
можно поискать по имени при помощи LookupAccountSid. Затем его можно вставить 
в дескриптор безопасности. То же самое можно сделать и с SID группы (если он есть). 
Обычно есть SID вызывающей стороны и одна из групп вызывающей стороны (однако 
системный администратор может вписать любые SID).

Таблица 11.17. Основные функции безопасности в Win32

Функция Win32

Описание

InitializeSecurityDescriptor

Подготовить к использованию новый дескриптор безопасности

LookupAccountSid

Искать SID для заданного имени пользователя

SetSecurityDescriptorOwner

Ввести SID владельца в дескриптор безопасности

SetSecurityDescriptorGroup

Ввести SID группы в дескриптор безопасности

InitializeAcl

Инициализировать DACL или SACL

AddAccessAllowedAce

Добавить новый ACE в DACL или SACL для разрешения доступа

AddAccessDeniedAce

Добавить новый ACE в DACL или SACL для запрещения доступа

DeleteAce

Удалить АСЕ из DACL или SACL

SetSecurityDescriptorDacl

Прикрепить DACL к дескриптору безопасности

В этот момент можно инициализировать список DACL (или SACL) дескриптора без-
опасности (при помощи InitializeAcl). Элементы ACL можно добавлять при помощи 
AddAccessAllowedAce и AddAccessDeniedAce. Эти вызовы можно повторять много раз 
(для добавления необходимого количества элементов АСЕ). DeleteAce можно использо-
вать для удаления элемента (при модификации существующего ACL). Когда ACL готов, 
можно использовать SetSecurityDescriptorDacl для прикрепления его к дескриптору 
безопасности. И наконец, когда объект создается, то свежеизготовленный дескриптор 
безопасности можно передать как параметр (чтобы прикрепить его к объекту).

11.10.3. Реализация безопасности

Безопасность отдельной системы под управлением Windows Vista реализована несколь-
кими компонентами, большинство из которых мы уже видели (работа в Сети — это со-

11.10. Безопасность в Windows 8   

1047

всем другая история, которая выходит за рамки данной книги). Регистрацией управляет 
winlogon, а аутентификацией — lsass. Результатом успешной регистрации является 
новая оболочка с графическим интерфейсом пользователя (

explorer.exe

) со связанным 

с ней маркером доступа. Этот процесс использует разделы SECURITY и SAM реестра. 
Первый настраивает общую политику безопасности, а второй содержит информацию 
безопасности для отдельных пользователей (это обсуждалось в разделе 11.2.3).

После того как пользователь зарегистрировался, все операции системы безопасности 
происходят тогда, когда объект открывается для доступа. Для каждого вызова OpenXXX 
требуется имя открываемого объекта и набор требующихся прав. Во время обработ-
ки открытия монитор безопасности (см. рис. 11.4) проверяет, есть ли у вызывающей 
стороны все необходимые права. Он выполняет эту проверку путем изучения маркера 
доступа вызывающей стороны и списка DACL, связанного с объектом. Он просматри-
вает по порядку список ACE внутри ACL. Как только он находит элемент, который 
совпадает с SID вызывающей стороны (или одной из групп вызывающей стороны), 
то найденный доступ принимается как окончательный. Если имеются все права, не-
обходимые для вызывающей стороны, то операция открытия завершается успешно; 
в противном случае она заканчивается неудачей.

Списки DACL могут иметь как элементы Deny, так и элементы Allow (как мы уже 
видели). По этой причине обычно запрещающие доступ элементы размещают в ACL 
впереди разрешающих, чтобы тот пользователь, конкретно которому отказано в до-
ступе, не мог его получить через «черный ход» (будучи членом группы, которая имеет 
законный доступ).

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

В Windows добавлено еще одно средство для решения возникающих при обеспечении 
безопасности системы (при помощи ACL) проблем. Это новый обязательный иденти-
фикатор уровня целостности

 (Integrity-level SID) в маркере процесса, причем объек-

ты указывают список ACE уровня целостности в списке SACL. Уровень целостности 
предотвращает доступ для записи к объектам (вне зависимости от того, какие АСЕ 
есть в DACL). В частности, схема уровня целостности используется для защиты от 
скомпрометированного процесса Internet Explorer, который, возможно, был атакован 
из-за скачивания кода с незнакомого веб-сайта. Internet Explorer с низкими правами 
(он называется Low-rights IE) работает с установленным в значение low уровнем 
целостности. По умолчанию все файлы и ключи реестра имеют уровень целостности 
medium, так что работающий с уровнем low браузер Internet Explorer не может их 
модифицировать.

За последние годы в Windows были добавлены и другие функциональные возможности 
системы безопасности. Начиная со второго пакета обновлений для Windows XP боль-
шая часть системы была скомпилирована с флагом (/GS), который выполнил проверку 
на многие типы переполнений буфера стека. Кроме того, был задействован бит NX 
архитектуры процессоров семейства AMD64, который ограничивает выполнение кода 
в стеке. Этот бит можно использовать даже при работе процессора в режиме х86. NX 
означает no execute (не выполнять) и позволяет помечать страницы (после чего код из 

1048  

 Глава 11. Изучение конкретных примеров: Windows 8 

этих страниц выполнить нельзя). Таким образом, если взломщик использует уязви-
мость переполнения буфера для вставки кода в процесс, то ему будет не очень легко 
перейти на этот код и начать его выполнение.

В Windows Vista используются и другие функции системы безопасности (чтобы по-
мешать взломщикам). Загружаемый в режим ядра код проверяется (на системах х64 
это делается по умолчанию), и загрузка производится только в том случае, если он 
подписан известным и доверенным авторитетным источником. Адреса загрузки DLL 
и EXE (и выделения стека) на каждой системе меняются, чтобы снизить вероятность 
того, что взломщик сможет использовать переполнение буфера, перейти на хорошо 
известный адрес и начать выполнение такого кода, который приведет к повышению 
его привилегий. Гораздо меньшее количество систем будет подвержено таким атакам 
(которые полагаются на то, что исполняемые модули находятся в стандартных адре-
сах). Системы, вероятнее всего, просто дадут сбой, что превратит атаку «повышение 
привилегий» в менее опасную атаку «отказ в обслуживании».

Еще одно изменение — появление того, что компания Microsoft называет управле-
нием учетными записями пользователей

 (User Account Control (UAC)). Оно решает 

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

Если при наличии UAC делается попытка выполнить операцию, требующую адми-
нистративного доступа, то система показывает специальный рабочий стол и перехва-
тывает управление, так что только ввод пользователя может разрешить этот доступ 
(аналогично тому, как работает 

CTRL+ALT+DEL

 по требованиям С2). Конечно, даже не 

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

Последнюю функцию системы безопасности Windows мы уже упоминали. Можно 
создавать защищенные процессы (protected processes), которые обеспечивают пери-
метр безопасности. Обычно периметр привилегий в системе определяет пользователь 
(представленный объектом маркера). Когда процесс создается, пользователь имеет 
доступ к процессу при помощи самых разных средств ядра (для создания процесса, его 
отладки, маршрутов и т. д.). Защищенные процессы изолированы от доступа пользо-
вателей. Изначально эта функция в Windows использовалась только в программном 
обеспечении управления цифровыми правами Digital Rights Management для улучше-
ния защиты контента. В Windows 8.1 сфера применения защищенных процессов была 
расширена на более нужные пользователю вещи вроде защиты системы от взломщиков 
(а не на защиту контента от атак со стороны хозяина системы).

Усилия компании Microsoft по повышению безопасности Windows в последние годы 
стали активизироваться, поскольку количество атак по всему миру растет. Некоторые 
из этих атак были очень успешными, они выводили из строя целые страны и большие 
корпорации и обошлись в миллиарды долларов. Большая часть атак использует не-

11.10. Безопасность в Windows 8   

1049

большие ошибки программирования, которые приводят к переполнению буфера или 
использованию памяти после ее освобождения, что позволяет взломщику вставить 
код, переписав адреса возврата, указатели на обработчики исключений, указатели на 
виртуальные функции и прочие данные, которые управляют выполнением программы. 
Многих из этих проблем можно избежать, если вместо языков С и С++ использовать 
безопасные в отношении типов языки. И даже при использовании этих небезопасных 
языков многих уязвимостей можно было бы избежать, если бы студентов лучше учили 
понимать важность проверки параметров и данных и осознавать многие опасности, 
унаследованные в API-функциях выделения памяти. В конце концов, многие из про-
граммистов компании Microsoft были студентами всего несколько лет назад (а многие 
из тех, кто сейчас читает эту книгу, являются студентами в настоящее время). Этим 
мелким ошибкам программирования, которые в языках, основанных на применении 
указателей, могут быть использованы как уязвимости, и способам избавления от них 
посвящено множество книг, например Howard and LeBlank, 2009.

11.10.4. Облегчение условий безопасности

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

И все же безопасность компьютерных систем можно повысить, если воспользоваться 
технологиями облегчения условий безопасности, затрудняющими использование уяз-
вимостей при их обнаружении. За 10 лет, предшествующих появлению Windows 8.1, 
в Windows постоянно добавляли усовершенствования в области технологий облегчения 
условий безопасности.

Таблица 10.18. Некоторые основные методы облегчения условий безопасности 
в Windows

Метод облегчения условий

Описание

Ключ компиляции /GS

Добавление стекового индикатора («канарейки») к фреймам 
стека для защиты целей условных переходов

Ужесточение исключений

Ограничение выбор кода, который может быть вызван 
в качестве обработчика исключений

NX MMU-защита

Пометка кода как неисполняемого, чтобы воспрепятствовать 
атаке на полезную нагрузку

ASLR

Рандомизация адресного пространства для затруднения 
атаки с использованием средств возвратно-
ориентированного программирования

1050  

 Глава 11. Изучение конкретных примеров: Windows 8 

Метод облегчения условий

Описание

Ужесточение контроля над 
кучей

Проверка распространеных ошибок использования кучи

VTGuard

Добавление проверок таблиц виртуальных функций

Проверка целостности кода

Проверка наличия криптографических подписей библиотек 
и драйверов

Patchguard

Обнаружение попыток изменения данных ядра, например, 
руткитами

Windows Update

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

Windows Defender

Встроенное основное антивирусное средство

Перечисленные облегчения условий безопасности препятствуют различным действи-
ям, необходимым для успешного широкого распространения вредоносного кода по 
системам Windows. Некоторые из них предоставляют собой глубоко эшелонирован-
ную оборону — defense-in-depth — против атак, способных обходить другие облегче-
ния условий безопасности. Ключ /GS выстраивает защиту против атак переполнения 
стека, которые могут позволить взломщикам изменять адреса возврата, указатели 
на функции и на обработчики исключений. Ужесточение исключений добавляет 
дополнительные проверки, чтобы можно было убедиться, что цепочки адресов об-
работчиков исключений не переписаны. Защита No-eXecute (NX MMU) требует, 
чтобы удачливому взломщику приходилось направлять счетчик команд не просто на 
полезные данные, но еще и на код, помеченный системой как исполняемый. Зачастую 
взломщики пытаются обойти NX-защиту, используя технологии возвратно-ориенти-
рованного программирования

 или возвращения к libC, которые направляют счетчик 

команд на фрагменты кода, позволяющие им выстраивать атаку. Рандомизация рас-
пределения адресного пространства

 (Address Space Layout Randomization (ASLR)) 

расстраивает такие атаки, затрудняя для атакующего предварительное определение 
местонахождения кода, стеков и других структур данных, загруженных в адресное 
пространство. Последние работы показали, как работающие программы могут заново 
рандомизироваться каждые несколько секунд, еще больше затрудняя проведение 
атак (Giuffrida et al., 2012).

Ужесточение контроля над кучей — это серия облегчений условий безопасности, 
добавленная к реализации куч в Windows, которая затрудняет использование таких 
уязвимостей, как запись за пределами границ распределения кучи, или некоторых 
случаев вычислений для использования блока кучи после его освобождения. VTGuard 
добавляет дополнительные проверки в конкретный уязвимый код, не давая восполь-
зоваться уязвимостью, относящейся к использованию памяти после ее освобождения 
и связанной с применяемой в С++ таблицей виртуальных функций.

Проверка целостности кода 

является защитой на уровне ядра против загрузки в про-

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

Таблица 10.18 (продолжение)