共用方式為


Двоичный анализатор 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 в виде списка ошибок. Типичный пример вывода приведен ниже:

clip_image001

Соответствующий список ошибок выглядит примерно так:

clip_image002

ИнтеграциясTeam Foundation Server (TFS)

При нажатии правой кнопки мыши на соответствующей ошибке и выбирается элемент CreateBinScopeWorkitems, появляется предварительно заполненная TFS форма содержащая информацию об ошибке:

clip_image003

Быстрый старт

Для установки 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. Отобразиться следующее меню опций инсталляции:

clip_image004

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 представлено ниже:

clip_image005

2. Укажите целевой путь (target path). В качестве цели обычно указывается путь к дистрибутиву продукта или файлу .msi. В последнем случае BinScope разархивирует файлы CAB и MSI и будет анализировать их. Так же может быть указан путь к папке, содержащей несжатые файлы. Во всех случаях убедитесь, что BinScope будет применен ко всем файлам, переданным заказчикам.
Примечание: Кнопка просмотра (“ ”) для Целевого Пути (target path) позволяет просмотреть информацию для любого бинарного файла. Например:

clip_image006

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, начнется процесс сканирования, при этом в окне будет отображаться ход процесса. Сбои и ошибки сканирования будут отображаться по мере появления. Дополнительно см. Просмотр результатов.
clip_image007

7. Откройте закладку Report для просмотра и сохранения отчета. Окно отчета отображает:
clip_image008

Дополнительно см. Viewing Results.

Для запуска BinScope (Дополнение к VisualStudio** ):

1. Убедитесь, что проект собран.

2. При необходимости изменить установки проверок BinScope по умолчанию вызовите форму Tools->Options->Security. По умолчанию BinScope дополнение к Visual Studio включает все проверки, требуемые SDL и, дополнительно, относящиеся ATL.

3. Выберите Tools -> Analyze с BinScope
-или-
Установив указателя мыши на проекте или решении, вызовите через контекстное меню (правая кнопка мыши) Scan с BinScope.
Для каждой проверки в окно Output будут выведены сообщения:

clip_image009
Ошибки будут отражены в окне Error List:

clip_image010

4. Введите ошибку как рабочий элемент в базу ошибок Team Foundation Server Вашего проекта следующим образом:

5. Если Вы еще не присоединены к серверу, выполите команду меню Tools -> ConnecttoTeamFoundationServer.
Возникнет диалог:
clip_image012

6. Выберите сервер для Вашего проекта из выпадающего списка и нажмите OK.
Отобразиться база данных сервера:
clip_image014

7. В окне Error list, нажмите правую кнопку мыши для одной или нескольких ошибок и выберите Create BinScope Workitem(s). Каждый пункт автоматически будет представлен в форме:

clip_image015

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 [Пройден]:

clip_image016

На вкладке Report приложения BinScope можно просмотреть детали проверок, вызвавших ошибки и сбои:

clip_image017

Как показывает пример, для 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 как ошибки:

clip_image010[1]

Включенные проверки

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 не следует проводить.

Перевод: Михаил Сидоров