Технологии компьютерной безопасности. Часть 2. AMD Execution Protection — маленькая революция

Что вообще может измениться от добавления в процессор одного-единственного бита? Да, именно так — технология Execution Protection заключается лишь в добавлении специального флага NX к стандартным флагам страниц виртуальной памяти². Звучит немного заумно, но на самом деле все довольно просто.

Чтобы разобраться в сути EP, начнем с азов и сперва рассмотрим, что такое виртуальная память и для чего она нужна. Пусть у нас есть операционная система и «населяющие» ее программы (приложения). Программы можно условно разделить на служебные, работающие незаметно для пользователя в фоновом режиме, и пользовательские (то есть «заметные» пользователю), причем одна и та же запущенная программа может запускать для себя множество вспомогательных программ. Процессор всего этого «не знает» — он работает с процессами. И служебные, и пользовательские программы, да и сама операционная система — все это процессы. Если открыть (по Ctrl+Alt+Del) Task Manager в операционных системах семейства NT, то можно увидеть разницу между прикладным приложением и процессом: посмотрите на скриншоты — запущено всего три задачи (задачами MS Windows называет приложения, с которыми может непосредственно работать пользователь) и целых 42 процесса. Какие-то из них обеспечивают работу пользовательских задач (winword.exe, far.exe), какие-то — фоновые приложения (ccapp.exe, proxyplus.exe), а какие-то удовлетворяют потребности других программ (rundll32.exe).

Строго говоря, процессор работает даже не с процессами, а с потоками исполнения (threads)³. С точки зрения процессора поток «живет» в оперативной памяти. Вот здесь и начинается самое интересное — в современной системе эта память для каждого процесса индивидуальна. А именно — со времен 386-х процессоров каждое запущенное приложение «живет» в собственном экземпляре памяти как будто бы оно было единственным приложением, запущенном на компьютере (это и есть механизм виртуальной памяти). То есть аналогия с офисом глубже, чем может показаться на первый взгляд, — как сотрудники одного подразделения работают в одном помещении и не видят остальные помещения и работающих там людей, так и все потоки одного процесса живут в общей памяти и не видят память других процессов. Получается так, как если бы для каждого процесса у нас был отдельный компьютер, на котором ничего больше не запущено. На самом деле, конечно, и компьютер у нас один, и память одна, просто процессы работают с «ненастоящей» — виртуальной памятью, а процессор на пару с операционной системой при обращении решают, какой адрес в физической памяти соответствует виртуальному. Для этого память «нарезается» страницами — кусочками фиксированного размера (4 Кбайт, 2 Мбайт или 4 Мбайт — в зависимости от выбранного режима), и где-то в память для каждого процесса кладется табличка, в которой задается соответствие между виртуальными и физическими страницами.

Помимо физических адресов виртуальных страниц, туда записывается и кое-какая дополнительная информация — флаги страниц. Эти флаги указывают, что со страницей можно делать, а что нельзя. Можно, например, сделать страницу доступной только для чтения или доступной только операционной системе. Вот мы и добрались до Execution Protection — эта технология просто добавляет в число «стандартных» флагов еще один (NX — Non eXecutive, запрещено исполнение кода из страницы). Зачем он нужен, мы сейчас и обсудим. Пока же проиллюстрируем вышесказанное схемой 1.

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

Без трансляции адресов было бы очень неудобно работать в многозадачной системе. Во-первых, потому, что мы могли бы случайно (или, наоборот, злонамеренно) испортить данные «чужого» процесса, а то и самой операционной системы. То есть любая ошибка в программе приводила бы к краху всей системы. Во-вторых, любому компилятору очень трудно работать, если он не знает заранее, где в памяти будет размещена создаваемая программа. В-третьих… впрочем, не будем забегать вперед. Сейчас нас интересует прежде всего первый пункт, из которого следует, что различные приложения не могут увидеть память друг друга⁴, и, казалось бы, поэтому хакерская программа не может напрямую, не прибегая к помощи операционной системы, повредить программу пользователя. Однако это не так — программы должны как-то общаться друг с другом, и вот как раз через эти «окна» в системе безопасности и возможна атака.

Execution Protection защищает от наиболее распространенного варианта подобной атаки — «ошибки переполнения буфера». Посмотрим, как организуется такая атака. Для этого нам потребуется чуть подробнее обсудить устройство потока выполнения.

Можно выделить четыре основных «слагаемых» потока. Во-первых, разные вспомогательные данные, используемые операционной системой (номер процесса — PID, указатели на таблицу трансляции виртуальной памяти, на стек потока и многое другое). С создания этой информации и возникает поток. Во-вторых, собственно код потока.

В-третьих, данные, потоком используемые. И в-четвертых — стек потока⁵. Вот со стеком-то и возникает проблема. В нем обычно сохраняется вспомогательная информация, в том числе довольно «интимного» свойства — точки возврата из вызванных в данный момент подпрограмм⁶.

Пока все о’кей, но в такой схеме есть одна уязвимость. Поток заполняет стек в обратном порядке — начиная с последней страницы, а данные в оперативную память записываются в порядке прямом. Если процесс запишет в стек слишком много данных, то он сотрет все записанное ранее, в том числе — точку возврата из текущей подпрограммы. Представьте, что наш служащий оставил в стеке место для записи, скажем, срочной информации, поступающей по телефону (буфер данных, на языке программистов). Когда кто-то звонит и что-то сообщает, то сообщение сначала записывается в отведенное место в стеке, а уже потом «переписывается начисто» в данные потока. Но что произойдет, если места для записи поступившей информации не хватает? Человек найдет еще один листик для записи информации, попробует мельче писать, что-то сокращать, на худой конец — сообщит о невозможности записи сообщения и предпримет что-то еще. Примерно так же будут действовать и грамотно написанные программы, однако, к сожалению, велик соблазн написать все «по-простому»⁷ — и в этом случае поток записывает переданную ему информацию поверх прежних записей.

Специальным образом сформировав обращение к такой программе, мы добьемся того, что процесс добровольно загрузит в себя вредоносный код и заодно запишет ссылку на него в качестве точки возврата из выполняемой им в этот момент подпрограммы. Как только подпрограмма, в которой осуществлялось чтение данных, закончит работу, процессор этот код сразу же запустит, и атака будет успешно завершена (см. схему 2). Атака, организованная по подобной схеме, и называется атакой переполнением буфера (buffer overflow). Легко видеть, что эта проблема вызвана целым рядом причин — небезопасным соглашением о схеме вызова подпрограмм, неудачной для данного случая организацией стека в x86, но главное — готовностью процессора выполнять код из любого места памяти.

В свое время, когда вершиной микропроцессорной архитектуры многие считали интеловский кристалл 80386, проблема успешно решалась так называемой сегментацией памяти. Не вдаваясь в подробности — оперативная память «нарезалась» небольшими кусочками-сегментами, и процессор работал не со всей памятью, а только с выбранными в данный момент сегментами. Вводилось сегментирование, правда, для решения совсем других проблем, но успешно решала и вопросы разделения памяти на участки кода, данных и стека. Однако с развитием процессоров сегментация использовалась все реже — возникающие проблемы проще решались механизмами виртуальной памяти. Возможность использования сегментов сохранена и по сей день, но обычно прибегают к «вырожденному» варианту — один огромный сегмент охватывает всю возможную память («плоская модель»), а в архитектуре AMD64 (например, в 64-разрядном режиме) сегментацию вообще уже нельзя использовать. В свое время механизмы виртуальной памяти казались «вспомогательными» и не предназначались для полноценного разделения данных, кода и стека. Однако операционная система могла таким образом оперировать флагами страниц, чтобы организовать защиту «своими силами». Например, обычно запрещена запись в страницы, содержащие код программы (программу нельзя изменять в ходе выполнения), а чтобы исключить возможность переполнения стека (ошибка, аналогичная переполнению буфера, только на более высоком уровне — закончилось место в стеке), его с обеих «сторон» обычно закрывают две страницы с максимально строгими ограничениями доступа (делать с этими страницами фактически ничего нельзя — любое обращение приведет к ошибке), надежно «закупоривающими» стек — выйти за его пределы невозможно⁸. Но вот бита, позволяющего запретить выполнение кода из страницы, до сих пор не было, — его-то и ввела AMD (бит NX). Теперь операционная система может просто-напросто пометить этим битом страницы стека. И хотя переполнить буфер будет по-прежнему возможно (тем самым испортив выполняющуюся программу), запуститься такой код уже не сможет — процессор выдаст ошибку доступа к памяти. В этом и состоит вся защита EP — в добавлении единственного бита, «забытого» в свое время при проектировании и ставшего сегодня одной из самых серьезных угроз компьютерной безопасности. Специалисты AMD и Microsoft полагают, что около половины апдейтов безопасности Windows от Microsoft за последние два года не потребовались бы, будь тогда технология, подобная EP. Читать дальше >>>

2. Строго говоря, это даже не отдельная технология, а часть куда более масштабной микроархитектуры AMD64. [вернуться]

3. Представьте себе здание (операционную систему) с множеством офисов, обслуживающих посетителей (пользовательские приложения — «задачи») и внутренние потребности здания. Офис может состоять из нескольких подразделений (процессов) — с одним работает пользователь, остальные обслуживают это подразделение. В нем есть и отдельные подразделения «только для служебного пользования», куда путь пользователю закрыт и с которыми работают только сами офисы. И, наконец, отдельные подразделения состоят из множества сотрудников (потоков исполнения), работающих внутри одного подразделения, но каждый — над своей задачей. Число таких «сотрудников» можно посмотреть в том же диспетчере задач, если включить отображение соответствующего столбца в настройках «Вид/Выбрать столбцы/Счетчик потоков». Мы же пока запомним главное: процессор оперирует потоками, и для каждого потока задано его место работы — процесс. [вернуться]

4. Есть, конечно, специальные средства, позволяющие создать память, «общую» для различных процессов, но на безопасность это не влияет. [вернуться]

5. Это «разделение» легко представить, если продолжить сравнение потока с офисным служащим: вспомогательные данные — это паспорт и пропуск служащего, код — записанные на специальных листочках инструкции о том, что ему нужно сделать, данные — листки с входными и выходными данными, а стек — пустые листы, которые служащий использует для черновиков и пометок о ходе работы. [вернуться]

6. Возвращаясь к нашему примеру: у служащего в инструкциях часто встречаются фразы вроде «см. документ такой-то, страница такая-то». Встретив подобную инструкцию, служащий помечает в стеке, где он остановился в текущем документе, заодно записывает все, о чем в настоящий момент думает, закрывает текущий документ и переходит по приведенной ссылке. Закончив работу там, он закрывает уже этот документ, смотрит в стеке, где он остановился в прошлый раз, и возвращается к исходному (до вызова подпрограммы) состоянию. [вернуться]

7. Этому немало способствуют стандартные функции чтения строк в языке C — очень часто используются версии, которые не проверяют, удается ли вместить данные в буфер или нет (они работают быстрее, короче называются, и именно они фигурируют в подавляющем большинстве учебных программ). И это — несмотря на наличие «проверяющих» версий тех же функций. Дело дошло до того, что в руководствах разработчика Unix-приложений крупными буквами подчеркивается опасность использования соответствующих функций и дается ссылка на их безопасные версии. К сожалению, заметного эффекта это пока не оказывает. [вернуться]

8. Кстати, легко видеть, что «переполнение буфера» фактически единственно возможный способ атаки, не требующий, чтобы вирус был явным образом запущен самой программой (как, например, в случае макровирусов для MS Word — текстовый редактор прекрасно осведомлен, что запускает какую-то программу, и Execution Protection здесь не спасает). [вернуться]