CC BY-NC-ND
22
Ю.К. Сергеев
АНАЛИЗ НЕКОТОРЫХ МЕХАНИЗМОВ УПРАВЛЕНИЯ ПАМЯТЬЮ ВИРТУАЛЬНЫХ МАШИН
Эволюция вредоносного ПО, выражающаяся в росте возможностей данных программ по осуществлению несанкционированных действий в ИС, ведет за собой развитие средств защиты. С каждым годом вирусы, сетевые черви и троянские программы становятся все интеллектуальнее, так что для борьбы с ними применяются все новые и новые средства, ищутся новые подходы. Зная установленные средства защиты информации (СЗИ) на атакуемом хосте, злоумышленник всегда может разработать новую технологию для скрытия вредоносного кода от заданных средств по борьбе с вредоносным ПО. Автор ставит целью спроектировать такую систему, в которой существует возможность обеспечить невидимость СЗИ для злоумышленника и/или вредоносных программ в рамках той ОС, в которую осуществляется вторжение, путем вынесения СЗИ за ее рамки. Для реализации такого рода архитектуры предлагается опираться на технологии виртуализации с применением гипервизора. Ввиду открытости исходных кодов (Open Source) для достижения этой цели автором используется ги-первизор Xen. Для того чтобы исследовать возможность применения данной технологии, необходимо рассмотреть механизмы, позволяющие изолировать виртуальные машины друг от друга. Одним из ключевых механизмов является управление оперативной памятью виртуальных машин.
Ключевые слова: гипервизор, механизмы управления памятью, средства защиты информации, изоляция виртуальных машин.
Управление памятью в системах, использующих виртуализацию, является одним из важнейших процессов с точки зрения безопасности. Неверная архитектура или недостаточность проверок выполнения тех или иных операций с памятью может приводить к серьезным последствиям - реализации угрозы НСД памяти
© Сергеев Ю.К., 2010
ОС в обход любых механизмов защиты, функционирующих внутри данной системы.
Выделение физической памяти виртуальным машинам должно осуществляться под контролем гипервизора с помощью встроенных механизмов проверки валидности таких операций.
Обеспечение безопасности при выделении и освобождении памяти
Для архитектуры x86 характерно выделение и освобождение оперативной памяти постранично. При создании нового домена, память которого обычно варьируется от 2 до 8 Гб, невозможно гарантировать, что найдется непрерывное пространство памяти такой длины, следовательно, физическая память обычно фрагментирова-на. Для создания имитации непрерывности пространства физической памяти для виртуальных машин (доменов) гипервизор, функционирующий в нулевом кольце процессора, реализует механизм объединения свободных блоков физической памяти в области псевдофизической памяти, т. е. создается уровень абстракции для доменов при работе с физической памятью.
Xen ведет таблицу соответствия физических (Machine Address, MA) и псевдофизических (Pseudo-Physical Address, PPA) адресов: MA->PPA. Для обратного преобразования к каждому домену прикрепляется таблица, содержащая обратное соответствие: PPA->MA.
Гипервизор
Физическая память
1 2 3 4 5 6 7 8 9 10
1 2 3 4
Домен 1
Псевдофизическая память
1 2 3 4
Домен 2
Псевдофизическая память
Рис. 1. Сопоставление физической и псевдофизической памяти
Возвращаясь к выделению памяти виртуальным доменам, стоит отметить, что каждый домен имеет максимальное и текущее выделение физической памяти, т. е. некоторые области памяти могут периодически выделяться разным доменам. Таким образом, в случае интенсивного использования оперативной памяти могут возникать случаи, когда та или иная область физической памяти после записи в нее информации может быть освобождена доменом и быть доступна другому. Если приложение, функционирующее в рамках виртуального домена, не осуществляет очистку памяти при ее освобождении и ОС также не контролирует данный процесс, может возникнуть угроза утечки информации по памяти.
Проведем эксперимент. На исходном компьютере под управлением Xen с 1024 Мб оперативной памяти зафиксируем максимальное количество памяти для привилегированного домена: root@sonic:/etc/xen# xm mem-set 0 400 root@sonic:/etc/xen# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 400 2 r----- 764.3
Запустим гостевой домен winxpl (256 Mb) под управлением Windows XP:
root@sonic:/etc/xen# xm create winxpl Using config file "./winxpl". Started domain winxpl root@sonic:/etc/xen# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 400 2 r----- 798.1 winxpl 8 256 1 -b---- 51.7
Сразу после загрузки и получения доступа к рабочему столу сделаем полный дамп памяти домена winxpl с помощью специально разработанной программы XenDumpHVM1:
root@sonic:/etc/xen# ./XenDumpHVM 8 1 > winxpl.core Данная копия памяти будет использована в качестве эталона системы сразу после загрузки. Затем запустим программу «Сапер» в данном домене и также сделаем дамп памяти, а затем завершим его работу:
root@sonic:/etc/xen# ./XenDumpHVM 8 1 > winxp1.core2 root@sonic:/etc/xen# xm shutdown winxpl Запустим другой домен winxp2 (512 Mb) также под управлением Windows XP для того, чтобы проверить путем создания третьего дампа памяти, что информация о запущенной в другой ОС программе будет доступна в оперативной памяти созданного:
root@sonic:~/.workspace/XenDumpHVM/Debug# xm create winxp2
Using config file "/etc/xen/winxp2". Started domain winxp2
root@sonic:~/.workspace/XenDumpHVM/Debug# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 400 2 r----- 1012.3 winxp2 9 512 1 r----- 5.6
root@sonic:/etc/xen# ./XenDumpHVM 9 1 > winxp2.core kirion@susic:~$ ls -lh winxp*
-rw-r--r-- 1 kirion kirion 267M 2009-10-26 23:40 winxp1.core -rw-r--r-- 1 kirion kirion 267M 2009-10-26 23:40 winxp1.core2
-rwx------ 1 kirion kirion 525M 2009-10-26 23:41 winxp2.core
В результате сравнения двух первых файлов видно, что в странице памяти № 57159 появились новые данные, соответствующие слепку памяти программы «Сапер», а большая часть оперативной памяти 3-го кольца процессора содержит нули, так как компьютер был только недавно запущен.
00000000 00000012 00000024 00000036 00000048 0000005а 0000006с 0000007е 00000090 000000а2 000000b4 ООООООсб 000000d8 ООООООеа
73 74 61 72 74 20 2D 20 67 6D 66 6Е 20 3D 2С 30 0А 53 FF00 F0 53 FF 00 F0 53 FF 00 F0 53 FF 00 F0 53 FF 00 F0 53 FF 00 F0 53 FF 00 F0 53 FF 00 F0 A5 FE00 F0 87 E9 00 F0 53 FF 00 F0 53 FF 00 F0 53 FF 00 F0 53 FF 00 F0 57 EF 00 F8 00 F0 FF F0 D2 EF 00 FF 00 F0 4A CO 53 FF 00 FF 00 F0 53
start - gmfn = 0.s
S...S...S...S.
The pattern you requested was not found.
End of file reached.
F0 53 FF 00 F0 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00 FO 53 FF 00
.S...S...S........
...S...S...S...S.. .s...n...M...A
...9...Y......
........n...s
...s.......>..
•S...S...S...S ...S...S...S.. S...S...S...S ...S...S...S...S.
.S...S...S...S.. ..S...S...S...S.,
0e16fc1e 0e16fc30 0e16fc42 0e16fc54 0e16fc66 0e16fc78 0e16fc8a 0e16fc9c 0e16fcae 0e16fcc0 0e16fcd2 0e16fce4 0e16fcf6 0e16fd08
66 85 CO 75 E5 FF 75 EO FF 75 08 57 FF D6 83 C4 ОС 85 f..u..u..u.w......
CO 75 BD 8D 4D DO E8 E5 BE 65 6E 64 20 2D20 67 6D 66 ,U-M...£nd-gmf 6E 20 3D 20 35 37 31 35 38 OA 73 74 61 72 74 20 2D 20 n=57158start-
67 6D 66 6E 20 3D 20 35 37 31 35 39 OA 40 00 00 00 84 gmfn=57159^)...
6A E4 73 00 00 00 00 2E 50 41 56 43 52 65 73 6F 75 72 p.....PAVCResour
63 65 45 78 63 65 70 74 69 6F 6E 40 40 00 00 00 00 84 ceException@@_
6A E4 73 00 00 00 00 2E 3F 41 56 43 52 65 73 6F 75 72 j.s.....?AVCResour
63 65 45 78 63 65 70 74 69 6F 6E 40 40 00 00 00 00 84 ceExBeption@@_
6A E4 73 00 00 00 00 2E 3F 41 56 43 55 73 65 72 45 78 j.s.....?AVCUserEx
63 65 70 74 69 6F 6E 40 40 00 00 00 00 84 6A E4 73 00 ception@@.....j.s. 00 00 00 2E 3F 41 56 43 43 6C 69 65 6E 74 44 43 40 40 ....'AVCOentDC@@ 00 84 6A E4 73 00 00 00 00 2E 3F 41 56 43 57 69 6E 64 ,.ji....?AVCWind 6F 77 44 43 40 40 00 84 6A E4 73 00 00 00 00 2E 3F 41 owDC@@.ji.....?A 56 43 50 61 69 6E 74 44 43 40 40 00 00 84 6A E4 73 00 VCRaintDC@@4s.
Рис. 2. Сравнение дампов памяти доменов путем поиска паттерна
В качестве паттерна для поиска было выбрано слово «АУСКезоигсеЕхсериоп». В первом файле такое слово не встречается. В третьем файле (дампе памяти домена шшхр2) те же самые данные с использованием паттерна «АУСКезоигсеЕхсер^оп» доступны, но по другому адресу, при этом информация после искомого слова не исказилась.
065ШЗс 065Ш4е 065Ш60 065Ш72 065Ш84 065Ш96 065Ша8 065ШЬа 0650Гс)сс 065Шс1е 065ШГО 0650Ге02 065(Яе14 0650Ге26
40 00 00 00 00 84 6А Е4 73 00 00 00 00 2Е ЗР 41 56 43 .....?АУС
43 6Р 60 62 6Р 42 6Р 78 45 78 40 65 6Е 64 20 20 20 67 Оэгг^сВэ(Б®атЬ-д 60 66 6Е 20 30 20 32 35 36 32 36 0А 73 74 61 72 74 20 тЙ1 = 25626ЛаП 20 20 67 60 66 6Е 20 30 20 32 35 36 32 37 0А 40 00 00 -дггтЙ1 = 25627.@.. 00 84 6А Е4 73 00 00 00 00 2Е 50 41 56 43 52 65 73 6Р . ..РАЖЯво 75 72 63 65 45 78 63 65 70 74 69 6Р 6Е 40 40 00 00 00 шоеЕжербопШ-00 84 6А Е4 73 00 00 00 00 2Е ЗР41 56 43 52 65 73 6Р . ._?АУСЛек> 75 72 63 65 45 78 63 65 70 74 69 6Р 6Е 40 40 00 00 00 игаеЕжвр&>п@@_.
00 84 6А Е4 73 00 00 00 00 2Е ЗР 41 56 43 55 73 65 72 .0.5.....?АУС115ег
45 78 63 65 70 74 69 6Р 6Е 40 40 00 00 00 00 84 6А Е4 Ехсер1юп@@..„0. 73 00 00 00 00 2Е ЗР 41 56 43 43 6С 69 65 6Е 74 44 43 Б... ,_'А\ШеПОС 40 40 00 84 6А Е4 73 00 00 00 00 2Е ЗР 41 56 43 57 69 Ш-р.—ШСМ
6Е 64 6Р 77 44 43 40 40 00 84 6А Е4 73 00 00 00 00 2Е паотОС@@.р.....
ЗР 41 56 43 50 61 69 6Е 74 44 43 40 40 00 00 84 6А Е4 ?АУСРа1пЮС@@4
Рис. 3. Выделение памяти доменом без ее предварительного освобождения
Таким образом, показан пример реализации утечки информации по памяти, возможность реализации которой происходит из-за отсутствия механизмов очистки памяти перед ее выделением другому домену.
Для предотвращения такого рода утечек необходимо реализовать такую функцию для страниц, подключаемых к домену. Операция присваивания страниц домену реализована в файле Ра§е_а11ос.с2 в функции alloc_domheap_pages(), которая вызывает универсальную функцию выделения памяти a11oc_heap_pages(). Последняя функция получает адрес, с которого она должна начать поиск, и количество страниц, которые нужно выделить. Затем осуществляет поиск после указанного адреса ближайших свободных страниц и возвращает информацию о них вызвавшей ее функции. Очистку можно производить непосредственно перед тем, как отдать страницы на присвоение домену.
Механизмы разделения памяти между доменами
Основным механизмом разделения памяти между доменами являются таблицы доступа (Grant tables). За каждым доменом закреплена собственная таблица, представляющая собой структуру данных, с помощью которой гипервизор определяет, какие привилегии были даны тому или иному домену для доступа к данному. Записи в таблице называются ссылками доступа (grant references). Создание и удаление ссылок осуществляется путем прямого доступа к таблице, что позволяет изменять привилегии доступа других доменов к областям памяти исходного без привлечения к этому процессу гипервизора. Для модификации таблицы доступа домена могут использоваться следующие четыре операции:
- предоставление права доступа субъекту (Grant foreign access). Создает новую запись в таблице и заполняет указанными правами доступа субъекта. Привилегии проверяются гипервизо-ром каждый раз, когда какой-либо домен запрашивает с помощью гипервызова (hypercall) ссылку для подключения указанной области памяти в свое пространство памяти (процедура маппирования - mapping);
- изъятие права доступа у субъекта (End foreign access). Если ссылка доступа в данный момент не используется никаким доменом, то данная операция удаляет запись доступа к заданной области;
- предоставление права передачи данных субъекту (Grant foreign transfer). Создает новую запись в таблице и заполняет указанными правами доступа субъекта. Привилегии проверяются ги-первизором каждый раз, когда какой-либо домен запрашивает с помощью гипервызова передать подключенную ранее область памяти обратно в исходный домен;
- изъятие права передачи данных субъекту (End foreign transfer).
Таким образом, гипервизор реализует дискреционный принцип
разграничения доступа, где:
- субъекты доступа - домены;
- привилегированные субъекты доступа - привилегированные домены;
- объекты доступа - любые области памяти любых доменов;
- монитор обращений - гипервизор Xen;
- правила разграничения доступа - таблица доступа для каждого домена с указанием привилегий других доменов при доступе к данному.
Виртуальная ОЗУ: Область кода
г::::-] Привилегированный домен
^В Субъект доступа
\ | 11. • | Doml | Transfer |
Область виртуальной ОЗУ с назначенным Access доступом
Область виртуальной ОЗУ с назначенным Transfer доступом
Рис. 4. Механизм дискреционного контроля доступа к памяти домена
При данном принципе разграничения доступа существует вероятность организации сценария «Троянский конь». Приведем пример. Домен А предоставляет доступ к области памяти {ат-ап} домену В. Домен В предоставляет доступ к области памяти {Ьк-Ь1} домену С. Для получения информации из домена А злоумышленнику достаточно установить программный агент в домене В для осуществления копирования данных {ат-ап} из А в область {Ьк-Ь1}, доступную С. Другими словами, возможно реализовать канал передачи информации между виртуальными компьютерами без использования сетевых технологий. Интересным является также тот факт, что для реализации этого канала нет необходимости встраивать какой-либо скрытый агент на атакуемый компьютер. Таким образом, данная атака будет «невидима» для любых существующих средств защиты, функционирующих внутри домена А, а ее обнаружение будет возможно только из привилегированных доменов.
Сегодня существует специальный модуль XSM (Xen Security Module), позволяющий интегрировать с гипервизором сторонние механизмы принудительного контроля доступа. В качестве архитектуры (framework) для реализации такого рода политик может быть использована Flask3. На основе этой архитектуры возможно формирование частных политик принудительного контроля доступа в зависимости от поставленных задач.
Реализация Flask относительно громоздкая, но зато очень гибкая, так как позволяет написать правила разграничения доступа для большинства политик принудительного контроля доступа. В случае определения необходимости использования только одной политики достаточно использовать API модуля XSM для написания собственной реализации.
Для обеспечения «невидимости» средства защиты, размещенного в выделенном домене безопасности, из защищаемого домена необходимо использовать политику принудительного доступа, которая не будет позволять «читать вверх» и «писать вверх», т. е. реализовать в дополнение к существующей дискреционной политике разграничения доступа к памяти между доменами следующую: субъекты отношений (домены): A, B; уровни доступа: System (S), Guard (G), Common (C); Типы доступов: R - чтение памяти, W - запись в память; C = {S,G,C} - решетка ценности; если C(A) > C(B), то A и A -^»B;
если C(A) = C (B), то B^^-A и A B
если C(A) < C(B), то A запрещен любой доступ к B. Иллюстрация данной политики приведена на рис. 5:
Рис. 5. Политика доступа для обеспечения «невидимости»
При этом изменять уровни доступа домена должен только пользователь, имеющий административные привилегии в домене с уровнем доступа System.
Заключение
В проведенном исследовании были:
- рассмотрены несколько основных механизмов управления памятью, реализованных в гипервизоре Xen;
- найдена уязвимость, связанная с выделением памяти домену после ее освобождения другим доменом;
- предложен путь нейтрализации данной уязвимости путем встраивания операций по очистке памяти в функцию alloc_heap_pages();
- рассмотрены механизмы разграничения доступа памяти для общей работы доменов с одной и той же областью памяти;
- предложена для реализации политика, позволяющая обеспечить «невидимость» средств защиты по оперативной памяти для любых вредоносных программ, функционирующих в рамках защищаемой ОС.
На основе полученных результатов можно сделать вывод о том, что построение архитектуры безопасности, в которой средство защиты становится «невидимым» для вредоносной программы вне зависимости от его возможностей в рамках защищаемой ОС, осуществимо с применением гипервизора Xen для рассмотренных операций с памятью.
В последующем исследования могут быть направлены на другие взаимодействия между доменами:
- механизмы обмена сообщениями между доменами, реализуемые через оперативную память;
- механизмы взаимодействия через сетевую подсистему Xen;
- возможности несанкционированного подключения блочных устройств хранения данных других доменов.
Примечания
1 Сергеев Ю.К. Использование технологий виртуализации для защиты информации // Вестник РГГУ. 2009. № 10. Сер. «Информатика. Защита информации. Математика». С. 98-109.
См.: Spector S. Xen Source Code Overview [Электронный ресурс] // Сайт Xen. [М., 2009]. URL: http://blog.xen.org/index.php/2009/06/15/xen-34-source-code-overview/ (дата обращения: 4.11.2009).
Spencer R, Smalley S, Loscocco P., Hibler M, Andersen D, Lepreau J. The Flask Security Architecture: System Support for Diverse Security Policies // Proceedings of the Eighth USENIX Security Symposium. 1999. Aug. P. 123-139. См. также: Coker G. Xen Security Modules (XSM). National Information Assurance Research Lab, National Security Agency (NSA): Presentation, 17 April 2007.
2
3
