Обеспечение безопасности Windows Vista на уровне кода

Многие пользователи спрашивают меня о технологиях /GS, SAL и ASLR, применяемых в Windows Vista. Вот мой ответ и он гораздо шире, чем просто /GS, SAL и ASLR по отдельности….

Данные технологии имеет две глобальные цели:
1) Сократить количество багов в коде
2) Затруднить использование багов, которые все-таки остались.

Сокращение количества ошибок в коде
Новая концепция разработки безопасного программного обеспечения Security Development Lifecycle (SDL) требует, чтобы разработчики регулярно посещали различные семинары, посвященные тому, как избежать ошибок в коде программных продуктов. Цели семинаров просты и вполне логичны – это не только для увеличения осведомленности сотрудников, но в первую очередь сокращение шансов, что инженер Microsoft допустит в коде ошибку. Все мы знаем, что без ошибок нигде не обходится, но я в данной статье попытаюсь рассказать, как в стенах компании Microsoft борются с имеющимися ошибками и теми, которые, скорей всего, все равно появятся в будущем. Дл этого придется вооружиться арсеналом инструментов, которыми мы – разработчики – пользуемся повседневно в своей работе. Используемые утилиты помогают отыскать потерянные комментарии SAL, выявить переполнение буфера, проблемы с границами массивов, переполнение целых значений, запрещенные API, запрещенные функции шифрования и многое другое. Мы также убрали из кода заблокированные функции. Функции типа strcpy, strncpy и их зловредые собратья также более недоступны. Я всегда был против использования strncpy и говорю людям, что замена strcpy на strncpy – не очень хорошая идея. Мы заменили данные функции аналогичными strsafe or SafeCRT. Это довольно-таки значительное изменение.

Компилятор C/C++, который входит в состав Visual Studio 2005, автоматически подсвечивает запрещенные API и на экране появляется следующее:

c:\code\stackaddr.cpp(14) : warning C4996: 'strcpy' was declared deprecated

Также функции, которые читают из или пишут в буфер, снабжаются комментариями SAL, чтобы помочь нашим утилитам найти трудно обнаруживаемые ошибки в коде.

Каждые несколько недель мы запускаем PREfix и проверяем базу исходных кодов Windows Vista. PREfix – это гораздо более продвинутый собрат PREfast. Кроме того, мы используем как внутренние, так и внешние тесты на проникновение в систему для компонентов, которые наиболее подвержены таким рискам. Мы также используем различные анализаторы синтаксиса. Данные части процесса тестирования управляются созданными нами моделями потенциальных угроз. Это позволяет лучше понять интерфейсы, уровни распределения привилегий и сетевого доступа, а также получить общее представление о потенциальных рисках.

После всей проделанной работы можно быть уверенным в 100% безопасности кода? Лично я сомневаюсь в этом. Причина довольно проста – мы делаем все, что только можно сделать, но Windows Vista будет находится на рынке в течение долгих лет и в эти годы, это я могу вам гарантировать, появятся новые техники атаки на ОС, а также всплывут новые баги. Мы, к нашему огромному сожалению, не можем предвидеть будущего. Кроме того, наш инструментарий далек от совершенства – мы знаем, что это не позволит нам найти все потенциальные уязвимости в коде. Именно по этой причине мы должны были добавить дополнительную защиту, о которой можно прочитать в следующем разделе.

Создание затруднений для использования эксплойтов
В Windows Vista появилась целая куча новых механизмов защиты, среди которых имеются совершенно новые, а также обновленные механизмы, использованные еще в предыдущих версиях Windows - Windows Server 2003 и Windows XP SP2. Данные механизмы призваны сократить шансы эскплойтов на успешную работу.

Так же хочу высказать свое мнение; что общий эффект от этих механизмов защиты гораздо сильнее суммарного эффекта каждого механизма в отдельности.

Предположим, что имеет место переполнение буфера в стэке кода какой-либо службы. C/C++-код в Windows Vista компилируется с флагом /GS и есть большой шанс, что переполнение стэка вызовет срабатывание /GS-защиты, завершив процесс вместо того, чтобы выполнить вредоносный код. Компилятор Visual C++ также реорганизует стэк, размещая буферы в более высших областях памяти по сравнению с не-буферами. Например, указатель функции хранится ниже буфера стэка, что означает, что код не сможет наполнить буфер настолько, чтобы тот стал уязвимым. Незаполнение буфера происходит значительно реже, чемa переполнение. Мы также переместили некоторые аргументы функций (к примеру, указатели) в более нижние области памяти. В последних сборках, вышедших после Beta 2, мы также расположили в случайном порядке различные потоки.

Предположим, что атакующий нашел способ обойти защиту /GS. Тут вступает в роль другой элемент защиты - No eXecute [NX иначе известен, как предотвращение выполнения данных - Data Execution Protection, DEP]. NX использует ресурсы процессора [большинство современных процессоров имеют поддержку NX] для предотвращения запуска кода в сегменте данных. Большинство традиционных эксплойтов содержат шел-код [прим. shellcode], который попадает в систему в качестве обычных данных, а запускается как код; NX может обнаруживать шел-код и предотвращать его запуск.

Предположим, что у атакующего нашлось время найти способ обойти и /GS и NX. Это, безусловно, возможно, если имеется достаточно “степеней свободы” в способе написания кода. Большинство эксплойтов обращается к различным Windows API, таким как socket() и LoadLibrary(). C рандомизацией адресного пространства [прим. address space layout randomization (ASLR)] данная задача заметно осложняется тем, что данные функции могут находится в любой из 256 возможных позиций. В ОС могут быть предсказуемые области и мы, осознав это, сделали ASLR настолько грамотно, как это было возможно. Но помните, в Windows Vista используется первая версия ASLR и с течением времени мы намерены улучшить ее, как было сделано с Windows Firewall.

Если же переполнение буфера повредило обработчик исключений [прим. exception handler] в стэке, это также не облегчит работу атакующему, как было ранее. ОС проверяет адреса обработчика и если текущий адрес отсутствует в списке действительных адресов исключений, которые входят в состав PE-заголовка, процесс завершается. Лист адресов добавляется строго через компилятор. Это функция редактора связей /SafeSEH.

Теперь предположим, что ошибка в коде, который подвержен переполнению буфера динамически распределяемой памяти. В данном случае /GS и SafeSEH не подходят, потому как эти механизмы защиты от переполнения буфера стека. Но мы внесли множество изменений в работу динамически распределяемой памяти, чтобы помешать успешному исполнению кода эксплойтов:

 Блоки динамически распределяемой памяти проверяются на контрольные суммы.
 Различные элементы блоков динамически памяти шифруются (XORd) различными значениями.
 Основной адрес блоков динамически распределяемой памяти - случайный
 Указатели функций, использованные динамически распределяемой памятью (к примеру CommitProcedure), шифруются алгоритмом XORd различными значениями.
 Большинство приложений Windows Vista просто завершают работу, если обнаруживается потенциально опасное функция в динамически распределяемой памяти.

Эдриан Маринеску, провел на конференции Black Hat презентацию, посвященную проблемам динамически распределяемой памяти, под названием “Windows Vista Heap Management Enhancements: Security, Reliability and Performance” [прим. Улучшения работы динамически распределяемой памяти в Windows Vista: безопасность, надежность и производительность].

Обратите внимание на то, что если баг – это integer overflow в обращении к новому оператору C++, код определит состояние в момент запуска и просто не выполнит перераспределение памяти вместо того, чтобы выполнить потенциально уязвимый код.

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

Новый способ защиты, использованный в Windows Vista, носит название Service hardening – укрепление служб. Это очень обширная тема, поэтому я хотел бы обратить ваше внимание всего лишь на две ее части. Первая – это возможность описания привилегий, необходимых для службы и появление менеджера управления службой - service control manager (SCM), который назначает привилегии процессам. Теперь в установочный код службы можно добавить код следующего:

//Assignment of required privileges

SERVICE_REQUIRED_PRIVILEGES_INFOW servicePrivileges;

servicePrivileges.pmszRequiredPrivileges = 

	(L"SeChangeNotifyPrivilege\0"

        L"SeCreateGlobalPrivilege\0");



BOOL fRet = ChangeServiceConfig2(

        schService,

        SERVICE_CONFIG_REQUIRED_PRIVILEGES_INFO,

        &servicePrivileges);

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

Другая сторона защиты служб – это службы, управляющие политиками сетевого брандмауэра, который намного усложняет запуск вредоносного кода в качестве сетевой службы. Безусловно, это не исключает проникновение, просто несколько затрудняет.

Кстати, брандмауэр по умолчанию включен! Но вы-то уже давно знаете.

Источник: http://www.blogs.msdn.com/
Перевод: deeper2k