среда, 11 сентября 2013 г.

РД НДВ - выполнение проверки "Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду"

Давно собирался сделать две вещи - начать писать статьи про проведение сертификационных испытаний по "РД НДВ" и выложить какой-нибудь свой проект на GitHub, переведя его в open-source. Пришло время совместить приятное с полезным и сегодня я открываю цикл статей про сертификацию программного обеспечения на соответствие требованиям по уровням контроля отсутствия недекларированных возможностей.


Начну, пожалуй, с середины - с проверки, которая называется "Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду", данная проверка присутствует на всех уровнях контроля и одинакова для всех уровней, кроме первого - на нем появляется дополнение "с использованием сертифицированных компиляторов". 

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

Итак, контроль соответствия исходных текстов объектному. Что же это такое? Всё просто - разработчик передает в испытательную лабораторию исходные тексты ПО и дистрибутив, при этом лаборатория должна убедиться, что исходные тексты соответствуют дистрибутиву. Сделать это, казалось бы, очень просто - компилируем исходные тексты, получаем объектные файлы, сравниваем их с дистрибутивом. Но на практике всё оказывается сложнее, разные компиляторы и сборщики работают по-разному. 

Объектные файлы исполняемых модулей, получаемые путем компиляции исходных текстов при проведении испытаний, могут отличаться от исполняемых модулей программного обеспечения, представленных на испытания, в части, касающейся служебной информации, генерируемой средой разработки, и зависящей от даты, времени и условий компиляции. Также ряд компиляторов при повторной сборке исходных текстов программ вносит изменения в порядок следования блоков команд, из-за чего бинарные файлы совпадают по содержимому и размеру, но отличаются при побайтовой проверке.

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

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

Общая методика такова - контроль соответствия исходных текстов ПО его объектному (загрузочному) коду проводится с использованием программного комплекса фиксации и контроля исходного состояния ФИКС (или АК-ВС, ПИК и т.д.) путем выбора режима работы «Сравнение файлов» с настройкой «для *.exe». В случае обнаружения расхождений при сравнении файлов, данные файлы повторно сравниваются с помощью утилиты адаптивного сравнения бинарных файлов. Данное средство анализирует смещение блоков в бинарных файлах.
 
Средство написано на PHP, запускается из командной строки с двумя параметрами - путями к сравниваемым объектным файлам. Пример вывода (результатов работы): 
Comparing file1.exe [272700 bytes] to file2.exe [272700 bytes]. 
Forward deep:1024
Backward deep:1024
Block size:16
272700/272700 [100%] errors: 0 [0%], warnings: 0 
Errors: 0/272700 [0%] 
Warnings: 0/272700 [0%]
Значения «Forward deep» и «Backward deep» - настраиваемые величины, дальность поиска блока в байтах, значение «Block size» - размер блоков. Данные величины подбираются экспертом в зависимости от типа бинарного файла и среды разработки и изменяются в коде файла bindiff.php с помощью любого текстового редактора. Возвращаемое значение «Errors» - количество различающихся байт, «Warnings» - количество передвижений блоков.  

Тут надо добавить, что вера в эту утилиту не должна быть абсолютной, в случае если расхождение подтверждается, несоответствующие блоки анализируются экспертом на предмет значимости и исполняемости различающегося кода. Для этого можно несколько раз повторить компиляцию на одном или разных компьютеров, вспомнить структуру PE-форматаELF-формата и других (в зависимости от ОС и типа программы) и так далее.

Если расхождения касаются служебной информации бинарных файлов и несущественно исполняемый код (не влияют на процесс выполнения), данные расхождения не являются несоответствием и проверка считается пройденной.

Утилита доступна на GitHub, лицензия - GNU GPL v.3. Форки, пуллреквесты и комментарии приветствуются. 

Что касается правильности такого метода проверки с точки зрения органов по сертификации и федеральных органов, вопрос открытый. Я использовал эти проверки при проведении испытаний в системе сертификации МинОбороны и вопросов к данному методу со стороны сотрудников федерального органа по сертификации и привлеченных экспертов не последовало. Но система сертификации ФСТЭК отличается от МинОбороны, как минимум, в ней есть еще и обычные органы по сертификации, которые проверяют результаты испытаний, поэтому гарантировать прохождение данной проверки в таком виде я не могу.

Коллеги, прошу высказывать своё мнение по данной проверки и возможности её использования при сертификации в системе ФСТЭК.

2 комментария:

  1. Для кого статья? То, что ты называешь "Мой метод" - грустные будни с 99 года для всех ИЛ... есть еще методы оценки до линковки и другие косвенные методы...
    Утилиты ФСТЭК предпочитает сертифицированные. Но завязываться на постоянно меняющиеся и неконтролируемые изменения компиляторов дело мало перспективное... В любом случае метод анализа требует подходы с учетом особенностей каждый раз...

    ОтветитьУдалить
  2. Да... и в сертификации важно доказательство...

    "Если расхождения касаются служебной информации бинарных файлов и несущественно исполняемый код (не влияют на процесс выполнения), данные расхождения не являются несоответствием и проверка считается пройденной."

    - это нужно доказать...

    ОтветитьУдалить