Двоичный анализатор BinScope
Введение
Данный документ содержит описание и руководство по применению инструмента Двоичный анализатор BinScope (BinScope Binary Analyzer - BinScope). Документ включает разделы:
· Обзор
· Быстрый старт
· Справочник по BinScope
Обзор
BinScope является инструментом верификации Microsoft, выполняющим анализ двоичных файлов в масштабе всего проекта с целью проверки соответствия требованиям и рекомендациям Microsoft’s Security Development Lifecycle (SDL). BinScope проверяет использование флагов компиляторов и компоновщиков, требуемых SDL, использование сборок со строгим именем, применение актуальных инструментов сборки, а также использование последней редакции заголовочных файлов ATL. BinScope также уведомляет об использовании опасных элементов, запрещаемых SDL.
Каждая проверка BinScope обращена на слабую сторону проекта, которой может воспользоваться атакующий злоумышленник. Выполнение требований, отслеживаемых BinScope не исключает полностью уязвимости проекта, но существенно затрудняет их использование. В дополнение отметим, что меры безопасности эффективны при комбинированном применении. Поскольку проверяемые уязвимости хорошо известны, даже единственная оставленная уязвимость, делает систему такой же незащищенной, как если бы остальные уязвимости также были бы открыты.
BinScope может функционировать как самостоятельное приложение и как дополнение (add-on) Visual Studio.
Проверки безопасности**
BinScope проверят, что при сборке выполнены следующие предварительные требования SDL:
· /GS flag -предотвращение переполнения буфера (вызовы проверки стека);
· /SafeSEH flag - обеспечение безопасной обработки исключений;
· /NXCOMPAT flag - предотвращение исполнения данных;
· /DYNAMICBASE flag - произвольное изменение базового адреса исполняемого образа при загрузке (ASLR);
· Strong-Named Assemblies - использование строгих имен сборок (в частности обеспечивает проверку целостности);
· Использование обновленных средств компиляции и сборки (минимум Visual Studio 2005 и выше);
· Использование проверенных заголовков ATL;
BinScope также выявляет потенциально опасные конструкции, запрещаемые или не рекомендуемые SDL:
· Не поддерживающая GS инициализация;
· Разделяемые области чтения/записи;
· Использование атрибута разрешения вызова с частичными полномочиями (allow partially trusted caller attribute - APTCA) для строгих сборок;
· Глобальные указатели на функции;
· ATLVulnCheck для классов, реализующих IPersistStreamInit (содержащий уязвимости в интерфейсе).
Для более подробной информации по проверкам BinScope, см. Включенные проверки.
Конфигурирование
BinScope позволяет пользователям избирательно включать и выключать проверки, а также добавлять новые проверки в форме отдельных подключаемых модулей (plug-in). По умолчанию:
· В графической оболочке включены все проверки на соответствие требованиям SDL.
· В режиме командной строки выполняются все проверки. Проверки на соответствие только требованям SDL производятся при задании флага /sdl.
ОтчетыBinScope**
BinScope представляет результаты в одной из двух форм, в зависимости от того, работает ли он как отдельное приложение или как дополнительный компонент, интегрированный в Visual Studio.
Результатыотдельногоприложения BinScope
Отдельное приложение BinScope выдает результаты как отчет в формате XML-файла. Преобразование XSL, включенное в дистрибутив BinScope, позволяет просматривать отчет в виде форматированного текста в Internet Explorer. Детальное описание файла отчета содержится в разделе Просмотр результатов.
Серьезность проблемы (Issue Severity)
В применении к SDL выделяются следующие уровни серьезности проблемы:
Level |
Severity |
Required Action |
1 |
SDL Required |
Fix |
2 |
SDL Recommended |
Investigate |
3 |
Non Security |
Informational only, no action required |
ОтчетыинтегрированногосVisual Studio компонентаBinScope
Результаты интегрированного в Visual Studio инструмента BinScope выводятся в окне Output как стандартный вывод, а также передаются в окно Error list в виде списка ошибок. Типичный пример вывода приведен ниже:
Соответствующий список ошибок выглядит примерно так:
ИнтеграциясTeam Foundation Server (TFS)
При нажатии правой кнопки мыши на соответствующей ошибке и выбирается элемент CreateBinScopeWorkitems, появляется предварительно заполненная TFS форма содержащая информацию об ошибке:
Быстрый старт
Для установки BinScope:
1. Убедитесь, что установленная система является последней версией Windows, поддерживаемой Вашим приложением.
2. Убедитесь, что .NET Framework 2.0 или более поздний выпуск установлен на Вашем компьютере.
3. Если планируется интеграция BinScope с Visual Studio, удостоверьтесь что VS 2008 или выше установлена на компьютере.
4. Перейдите по ссылке https://go.microsoft.com/?linkid=9678113 и загрузите BinScopeSetup.msi.
5. Запустите BinScopeSetup . msi. Отобразиться следующее меню опций инсталляции:
6. По умолчанию будут установлены и отдельное приложение и интегрированная с Visual Studio версии BinScope. Если у Вас нет Visual Studio 2008 или планируется установка только изолированного приложения, отключите опциюIntegrateintoVisualStudio 2008 ( ifinstalled ) .
7. Нажмите Next и следуйте инструкциям меню для завершения установки.
Для отдельного приложения BinScope, исполняемый модуль BinScope . exe и связанные файлы будут установлены в каталог по умолчаниюC :\ ProgramFiles \ Microsoft \ (возможен выбор другого каталога) в подкаталог SDLBinScope \ .
Для интегрированного с For Visual Studio компонента BinScope, необходимые файлы будут установлены по умолчанию в каталог C :\ ProgramFiles \ Microsoft \ (возможен выбор другого каталога) в подкаталог SDLBinScopeforVisualStudio\.
Для запуска BinScope (отдельное приложение):
Примечание: Приведенная ниже инструкция показывает, как запустить BinScope используя графический интерфейс. BinScope также может быть стартован из командной строки или из Visual Studio. Детали см. в Использование BinScope.
1. Запустите ярлык BinScope из меню Старт или открыв командное окно в папке с установленным BinScope и наберите BinScope. Окно BinScope представлено ниже:
2. Укажите целевой путь (target path). В качестве цели обычно указывается путь к дистрибутиву продукта или файлу .msi. В последнем случае BinScope разархивирует файлы CAB и MSI и будет анализировать их. Так же может быть указан путь к папке, содержащей несжатые файлы. Во всех случаях убедитесь, что BinScope будет применен ко всем файлам, переданным заказчикам.
Примечание: Кнопка просмотра (“ … ”) для Целевого Пути (target path) позволяет просмотреть информацию для любого бинарного файла. Например:
3. Измените путь по умолчанию для Output Log при необходимости. ПО умолчанию путь указывает на каталог BinScopeLogs\ рабочего стола. Выходные файлы представляют XML-файлы с именем BinScope -< machinename >-< YY >_< MM >_< DD >_< hh >_< mm >_< ss >. xml.
4. В группе Options введите каталог или сервер, содержащий закрытые символы проекта. Закрытые символы содержат полную символьную информацию, в отличие от открытых символов. Все символы содержаться в файлах . pdb. По умолчанию путь задается в переменной среды _ NT _ SYMBOL _ PATH. Если _ NT _ SYMBOL _ PATH не задан, BinScope использует путь SRV ** http :// msdl . microsoft . com / download / symbols.
Примечание: BinScope при поиске символов использует те же самые методы, что и отладчик. Наиболее общим способом указания инструментам отладки нужных символов является задание переменной среды NT _ SYMBOL _ PATH. Для проверки корректности пути используйте symchk . exe из инструментов отладки для Windows (https://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx#a).
5. Задайте проверки, которые планируется выполнить в области Checks. По умолчанию выбраны все проверки, требуемые SDL, а также проверки, относящиеся к ATL. Дополнительно см. Включенные проверки.
6. Нажмите кнопку Run. Возникнет окно Run, начнется процесс сканирования, при этом в окне будет отображаться ход процесса. Сбои и ошибки сканирования будут отображаться по мере появления. Дополнительно см. Просмотр результатов.
7. Откройте закладку Report для просмотра и сохранения отчета. Окно отчета отображает:
Дополнительно см. Viewing Results.
Для запуска BinScope (Дополнение к VisualStudio** ):
1. Убедитесь, что проект собран.
2. При необходимости изменить установки проверок BinScope по умолчанию вызовите форму Tools->Options->Security. По умолчанию BinScope дополнение к Visual Studio включает все проверки, требуемые SDL и, дополнительно, относящиеся ATL.
3. Выберите Tools -> Analyze с BinScope
-или-
Установив указателя мыши на проекте или решении, вызовите через контекстное меню (правая кнопка мыши) Scan с BinScope.
Для каждой проверки в окно Output будут выведены сообщения:
Ошибки будут отражены в окне Error List:
4. Введите ошибку как рабочий элемент в базу ошибок Team Foundation Server Вашего проекта следующим образом:
5. Если Вы еще не присоединены к серверу, выполите команду меню Tools -> ConnecttoTeamFoundationServer.
Возникнет диалог:
6. Выберите сервер для Вашего проекта из выпадающего списка и нажмите OK.
Отобразиться база данных сервера:
7. В окне Error list, нажмите правую кнопку мыши для одной или нескольких ошибок и выберите Create BinScope Workitem(s). Каждый пункт автоматически будет представлен в форме:
8. Заполните форму как требуется. Форма конфигурируется на уровне узла и состав полей может различаться. Приведенная форма содержит поле приоритета, но не важности ошибки, но, возможно Вам это поле потребуется. В любом случае, поскольку по умолчанию проверки проводятся на соответствие требованиям SDL, для нарушений устанавливается уровень важности (Severity) 1. Для каждого элемента выполнитеFile -> SaveNewBug или нажмите ctrl - S для сохранения ошибки.
Справочник BinScope
· Применимость
· Дополнительные инструменты
· Проверяемые требования SDL
· Использование BinScope
· Режим командной строки
· Просмотр результатов
· Включенные проверки
· Проверки BinScope и флаги компилятора/компоновщика
· Известные ошибки
· Часто задаваемые вопросы (FAQ)
Применимость
BinScope функционирует под управлением следующих операционных систем (и сервисных пакетов):
· Windows Server 2003, Windows Vista.
· 32-bit and 64-bit systems.
Матрицаприменимости**
Приведенная ниже матрица показывает, какие проверки к каким типам бинарных файлов могут быть выполнены. Помните, то проверки BinScope не применимы к компилированным файлам help,ресурсным DLL, или DLL не поставляемым с продуктом.
Binary Type |
/GS |
/SafeSEH |
/NXCOMPAT |
Non-GS Friendly Init |
Read/Write Shared Sections |
APTCA |
ASLR |
ATL Version Check |
ATL Vuln Check |
Fully Managed |
No |
Yes |
No |
No |
No |
Yes |
No |
No |
No |
Partially Managed |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
||
Help File |
No |
No |
No |
No |
No |
No |
No |
No |
No |
Resource-Only DLLs (PDBs usually not generated) |
No |
No |
No |
No |
No |
No |
No |
No |
No |
64-Bit Unmanaged Binaries |
Yes |
No |
Yes |
Yes |
Yes |
No |
Yes |
Yes |
Yes |
Unmanaged Executable |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
Yes |
Yes |
Yes |
Kernel Mode Code |
Yes |
Yes |
No |
Yes |
Yes |
No |
No |
No |
No |
Дополнительные инструменты
Отсутствуют.
Проверяемые требования SDL
BinScope является основным средством проверки двоичных файлов на соответствие требованиям, определенным для Security Development Lifecycle Verification Phase (https://msdn.microsoft.com/en-us/library/cc307418.aspx).
Следующие проверки устанавливают соответствие требованиям SDL (SDL Implementation phase requirements):
· ATLVersionCheck
· ATLVulnCheck
· /GS
· /SAFESEH
· R/W shared PE sections
· APTCA usage
· ASLR checks
· /NXCOMPAT
· Dynamic Base Check/ASLR
· Strong-named assemblies check
Детали см. Включенные проверки.
Примечание: В случае возникновения обстоятельств, исключающих возможность удовлетворить требованиям SDL для определенного файла, существует возможность исключения файла из списка проверок.
Дополнительные проверки (не SDL)
BinScope может также выполнять проверки требований, не связанных с SDL:
· FP Check (проверка использования глобальных указателей на функции)
Использование BinScope
BinScope может быть использован в режиме GUI, командной строки, или дополнения интегрированного с Visual Studio.
Режим GUI и Visual Studio определен в разделе Быстрый старт. Режим командной строки определен в последующих разделах.
Режим командной строки
Для запуска BinScope в режиме командной строки, откройте окно команд в каталоге с установленным BinScope
Синтаксис командной строки BinScope:
BinScope . exe [< options ] < target >
Опции
Опция |
Описание |
/(c)hecks check1 check2… checkN |
Включенные проверки |
/listhecks (/lc) |
Открывает графический интерфейс для перечисленных проверок |
/target <path> |
Целевой каталог |
/(o)utput <path> |
Каталог вывода результатов |
/(s)ympath |
Путь к закрытым символам |
/(x)slt |
Подключение XSLT |
/(g)ui |
Открыть графический интерфейс BinScope |
/sdl |
Выполнение только проверок на соответствие требованиям SDL |
/(save)config <file> |
Сохранить опции в конфигурационном XML-файле |
@<config_file>.xml |
Использовать опции конфигурационного XML-файла |
Просмотр результатов
BinScope отображает результаты различным образом в зависимости от режима запуска.
ВыводизолированногоприложенияBinScope**
Вывод BinScope выполняется в формате XML-файла. Форматированный текст XML-файла отображается на вкладке Report и может быть выведен в Internet Explorer. Следует учесть, что существует три типа сообщений: Failed [Сбой], Didn’t Complete [Ошибка], и Passed [Пройден]:
На вкладке Report приложения BinScope можно просмотреть детали проверок, вызвавших ошибки и сбои:
Как показывает пример, для client.exe не прошла проверка SasfeSEH, поскольку флаг /safeseh не был установлен, и для MRC42D.DLL проверка также не прошла, поскольку файл PDB не был найден.
Только эта форма отчета внутри BinScope может быть использована для получения деталей проверки. Любой другой выходной XML-документ, содержащий отчет, также может быть загружен через элемент Generatereportforcurrentorotherscanresult в левом нижнем углу экрана.
Вывод дополнения ( add - on ), интегрированного с BinScopeVisualStudio
Дополнение BinScope интегрированное с Visual Studio выводит результат в стандартное окно вывода (Output) Visual Studio. Ниже приведен пример содержания сообщений:
BinScope: scanning project output folder c:\COM_project\client\Debug\client.exe
BinScope: using the following checks: GSCheck SafeSEHCheck APTCACheck GSFriendlyInitCheck NXCheck DBCheck SharedSectionCheck CompilerVersionCheck
BinScope: scannning c:\COM_project\client\Debug\client.exe...
BinScope: c:\COM_project\client\Debug\client.exe has PASSED the GSCheck
BinScope: c:\COM_project\client\Debug\client.exe has PASSED the SharedSectionCheck
BinScope: c:\COM_project\client\Debug\client.exe has FAILED the NXCheck
BinScope: c:\COM_project\client\Debug\client.exe has PASSED the GSFriendlyInitCheck
BinScope: c:\COM_project\client\Debug\client.exe has FAILED the SafeSEHCheck
BinScope: No SAFESEH (LOAD_CONFIG absent)
BinScope: c:\COM_project\client\Debug\client.exe has FAILED the DBCheck
BinScope: c:\COM_project\client\Debug\client.exe has PASSED the CompilerVersionCheck
BinScope: scanning project output folder c:\COM_project\client\Debug\client.exe
BinScope: using the following checks: GSCheck SafeSEHCheck APTCACheck GSFriendlyInitCheck NXCheck DBCheck SharedSectionCheck CompilerVersionCheck
BinScope: scannning c:\COM_project\client\Debug\client.exe...
BinScope: c:\COM_project\client\Debug\client.exe has PASSED the GSCheck
BinScope: c:\COM_project\client\Debug\client.exe has PASSED the SharedSectionCheck
BinScope: c:\COM_project\client\Debug\client.exe has FAILED the NXCheck
BinScope: c:\COM_project\client\Debug\client.exe has PASSED the GSFriendlyInitCheck
BinScope: c:\COM_project\client\Debug\client.exe has FAILED the SafeSEHCheck
BinScope: No SAFESEH (LOAD_CONFIG absent)
BinScope: c:\COM_project\client\Debug\client.exe has FAILED the DBCheck
BinScope: c:\COM_project\client\Debug\client.exe has PASSED the CompilerVersionCheck
Дополнительно неудавшиеся проверки отображаются в окне Error list как ошибки:
Включенные проверки
BinScope включает самые различные проверки на соответствие требованиям как SDL, так и не-SDL. Каждая проверка реализуется как один или несколько подключаемых модулей с именем, соответствующим каждой проверке. Проверки описаны в следующей таблице.
Check/Plugin |
Описание |
ATLVersionCheck |
Проверка версии заголовков ATL. Только для COM. |
ATLVulnCheck |
Определяет использование уязвимого интерфейса IPersistStreamInit. Только для COM. |
APTCACheck |
Вызывает сообщение об ошибке в том случае, если верифицируемый бинарный файл является управляемой строгой сборкой, с указанным APTCA атрибутом (AllowPartiallyTrustedCallersAttribute). Такой атрибут потенциально опасен и не должен входить в безопасный продукт. |
SectCheck |
Сообщает об ошибке в случае, если двоичная сборка PE-формата содержит секции, отмеченные как разделяемые и для записи. |
GSCheck |
Проверяет, что флаг компилятора /GS был использован для компиляции всех модулей. Возможно, не все модули были откомпилированы с этим флагом. В том случае, если модули были переданы Вам сторонним производителем, то с ним следует связаться для получения безопасных модулей. Помните, что: GSCheck требует доступа к символьной информации. Убедитесь, что требуемая символьная информация доступна (например, установив _NT_SYMBOL_PATH=SRV*\\symbols\symbols). Более подробно см. /GS flag. |
SafeSEHCheck |
Проверят, что компоновка была выполнена с флагом /SAFESEH. Не использование /SAFESEH делает бесполезным защиту, обеспечиваемую опцией /GS. Примечание –для того, чтобы компоновка с /SAFESEH была возможна, все объектные файлы должны быть совместимы с /SAFESEH. Более подробно см. /SafeSEH flag . |
FPCheck |
Проверка использования глобальных указателей на функции. Переписывание статических буферов может также изменить и эти указатели, что приводит к уязвимости приложения. Эта проверка не охватывается /GS опцией. Эта проверка не требуется SDL, но рекомендуется проверять статические буферы на предмет возможного переполнения. FPCheck также требует доступа к символьной информации (см выше /GS проверку). |
SicCheck |
Позволяет идентифицировать случаи, когда модули не имеют инициализации /GS. При использовании /GS при загрузке модуля должна быть проведена инициализация для создания структур, требуемых GS. Обычно выполняется функцией типа CRT startup. Однако, если выполняемый модуль собран таким образом, что не содержит кода инициализации (например, компоновщику указан флаг /NOENTRY) и не указана процедура инициализации GS, то эффекта от указания флага GS нет и продукт остается незащищенным. Дополнительно см. Non-GS friendly initialization |
CompilerCheck |
Проверят, что С/C++ модули были откомпилированы с использованием версии не ниже, чем требует SDL. Конкретно, BinScope проверяет что C/C++ компилятор (cl.exe)имеет по меньшей мере версию 14.00.50727 а компилятор CVTRES, компилятор MASM и компоновщик имеют по меньшей мере версию 8.00.50727. Все этьи версии входят в состав Visual Studio 2005. |
DBCheck |
Проверят, что двоичные файлы поддерживают возможность ASLR. |
SNCheck |
Проверят использование строгих имен сборок. Строгое имя включает цифровую подпись образующую уникальное (криптографическое) имя для управляемой сборки. Целостность сборки при этом защищена цифровой подписью. Ни имя, ни тело сборки не могут быть изменены без повторения процедуры компиляции и компоновки. |
NXCheck |
Проверяет, что сброка использует аппаратный запрет на исполнение данных. Более подробно см. /NXCOMPAT flag. |
Проверки BinScope и флаги компилятора/компоновщика
В данном разделе приводиться подробная информация о проверках BinScope связанных с флагами компиляции и компоновки.
/ GS флаг
Цель: Этот параметр обеспечивает проверку целостности стека функции, обеспечивая тем самым защиту от переполнения локального буфера. При установке флага /GS изменяются пролог и эпилог вызываемой функции (вызываемые, соответственно, до и после выполнения тела функции). Пролог заносит в стек сторожевые биты (security cookie), копируя при этом эталонные сторожевые биты (их инициализация происходит при загрузке исполняемого образа и передаче управления точке входа), и записывает в стек адрес возврата, модифицированный операцией xor со сторожевыми битами. Эпилог выполнят проверку целостности сторожевых бит (считавая их из стека и сравнивая с эталоном) и выполняет возврат управления, восстанавливая при этом адрес возврата.
Рискбезопасности: Очень высокий. Модули, не защищенные GS являются уязвимыми для атак переполнения.
История: был введет в 2002 с .NET 1.0 [версия компилятора C++ 7.0, VS.NET] в упрощенной форме. Далее был расширен в .NET 1.1 [7.1], и затем, в .NET 2.0 [8.0 "Whidbey", или VS 2005]. На данный момент, только 8.0 /GS обеспечивает достаточный уровень защиты.
История SDL: является требованием SDL 2.0.
Особенности BinScope: база символов [PDBs] должна быть доступна для проверки. В противном случае выдается сообщение об ошибке.
Применимость: проверка /GS может не выполняться для полностью управляемых сборок и для двоичных файлов, не содержащих исполняемый код. Также BinScope не обнаруживает использование /GS в двоичных файлах, полученных при помощи 7.0 C++ компилятора.
/ SafeSEH флаг
Цель: При задании параметра / SAFESEH, образ создается компоновщиком только в том случае, когда возможно создание таблицы обработчиков безопасных исключений образа. Эта таблица используется операционной системой для определения допустимых для образа обработчиков событий.
Задание этот параметра приводит к тому, что адреса всех валидных обработчиков исключений заносятся в таблицу безопасных исключений. Если обработчик отсутствет в таблице, то он не будет выполнен, а потому передача управления обработчику, внедряемому атакующим посредством переполнения буфера, будет затруднительна. Обычно сценарий подобной атаки проходит в два шага. Сначала атакующий, при вызове функции, вызывает переполнение буфера и переопределяет в стеке обработчик исключения (записывая свои данные), затем функция генерирует корректное исключение и управление передается атакующему. Поскольку управление передается обработчику исключений за пределами функции, проверки /GS не вызываются, а потому /GS без /SafeSEH не эффективен.
Рискбезопасности: Высокий. Функции в исполняемом файле могут вызывать исключения, которые могут быть использованы посредством переполнения буфера для перехвата управления. История: Введен в 2003 в компиляторе 7.1 C++ [.NET 1.1 или VS 2003]
История SD: Стал требованием в SDL 2.0.
Особенности BinScope: Нет особенностей; не требуется символьная информация в PDB.
Применимость: Не имеет смысла для 64-bit двоичных файлов, поскольку они не хранят обработчики сообщений в стеке. SafeSEH требует поддержки на уровне ОС, реализуемой в XP SP2 и выше, поэтому проверка не будет проведена для более ранних ОС .
Инициализация не поддерживающая GS( Non - GSfriendlyinitialization )
Цель: Одной из первых задач, выполняемых при загрузке исполняемого образа, является инициализация /GS сторожевых битов (security cookie) случайным уникальным значением. Эта функция инициализации может быть переопределена при изменении точки входа исполняемого образа. При этом ответственность за вызов соответствующей процедуры инициализации лежит на разработчике. Любой вызов другой функции до инициализации /GS сопровождается записью в стек функции сторожевых битов, установленных по умолчанию, которое может быть известно атакующему. Воспользоваться при этом уязвимостью через переполнение буфера, так же просто, как и при отсутствии /GS.
Риск безопасности: Средняя или высокая, в зависимости от того, будут ли вызваны инициализирующие сторожевые биты (cookies) функции.
Особенности BinScope: Требуется символьная информация в PDB.
Применимость: Не применимо для управляемых сборок.
/ NXCOMPAT флаг
Цель: Указывает на то, что исполняемый файл был проверен на совместимость с функцией предотвращения исполнения данных (DEP) Windows. DEP предотвращает выполнение инструкций, хранящихся в страницах памяти, кроме тех страниц, которые явно помечены как исполняемые. Эта опция является умолчанием для XP SP2 и выше. Отсутствие флага повышает риск успеха кодовых вставок при переполнении буфера.
Включение GS при отключенном /NXCOMPAT сводит возможности атакующего к переполнениям глобальных буферов или кучи.
Примечание: установка /NXCOMPAT для EXE оказывает влияние на весь процесс, включая все загруженные модули.
Риск безопасности: Средний, если установлен /GS .
История: Введен в 2005 [8.0 "Whidbey"].
История SDL: Был принят как требование в 2005.
Особенности BinScope: Требуются файлы символов PDB.
Применимость: Не имеет смысла для управляемых сборок поскольку JIT (just-in-time) запускает некоторые инструкции исполнения генерируемые на лету со страниц данных.
/ DYNAMICBASEфлаг**
Цель: Этот параметр изменяет заголовок исполняемого файла, чтобы указать, необходимо ли произвольно изменять базовый адрес приложения во время загрузки.Технология ASRL поддерживается только операционной системой Windows Vista и более поздними версиями операционных систем.
ASLR должна быть включена для всего машинного кода (неуправляемых сборок) для предотвращения атаки возврата управления при вызове функций библиотеки libc return-to-libc class of attacks. Поддержка такой проверки требует установки флага /DynamicBase во всех заголовках PE всех модулей. Этот флаг устанавливается Visual Studio 2005 SP1 или выше. Ранние версии компоновщиков не поддерживают данный флаг.
Рискбезопасности: Высокий. ASLR может существенно снизить эффективность атак возврата управления (сравнить с 1/256 для модулей без ASLR).
История:Введена в Visual Studio 2005 SP1.
ИсторияSDL: Требование SDL 4.1.
Особенности BinScope: Не требует файлов PDB.
Применимость: Неуправляемые сборки, реализующие интерфейс IChecks определенный в BinScopeLib.dll
Известные ошибки
В таблице приведен список известный список ошибок BinScope.
Описание ошибки |
Будет исправлена |
Смягчение |
Дополнительно |
В редких случаях проверки небезопасной к /GS инициализации дают неправильные положительные результаты. |
Следующие выпуски |
Обследование вручную |
Часто задаваемые вопросы (FAQ)
Вопрос – Что такое файл PDB?
Ответ – PDB это сокращение от “program database.” Файл PDB содержит информацию о символах отладки и требующуюся инкрементальной сборке. Дополнительно см. https://msdn.microsoft.com/en-us/library/yd4f8bd1(VS.71).aspx.
Вопрос – Что случилось с проверкой Hotpatch?
Ответ – Проверка Hotpatch была удалена из BinScope, поскольку более не соответствует требованиям SDL.
Вопрос – В чем разница между сообщениями типа "Error" и "Fail"?
Ответ – "Error” означает, что проверка не проведена. “Fail” означает, что проверка произведена, ее результат отрицателен и требуется исправление проблемы.
Вопрос – BinScope завершается с кодом ошибки 5 при запуске в режиме командной строки. Что это означает?
Ответ – Возвращаемый код ошибки складывается из количества сообщений ”Error” и ”Fail” , выявленных BinScope. Завершение с кодом 0 говорит об отсутствии проблем при проверке.
Вопрос – Я использую символьную информацию, но BinScope сообщает "Required debug information in CodeView format is not available.”
Ответ – Обычно такое сообщение возникает, когда генерируются не все символы. Попробуйте воспользоваться (генерировать) закрытый или полный набор символов.
Вопрос – Могу ли я использовать BinScope для бинарных модулей, которые сгенерированы Sgen.exe и не имеют PDB файлов (например, автоматически генерированные dll-сериализаторы для XML)?
Ответ – В том случае, если они были сгенерированы компилятором, удовлетворяющим требованиям SDL, проверку BinScope не следует проводить.
Перевод: Михаил Сидоров