72
производят приоритезацию найденных дефектов. Наиболее высокий приоритет
назначается ошибкам, которые могут вызвать уязвимости. Исправление таких
дефектов позволит специалистам ОАО Аурат повысить безопасность
исполняемого кода.
Для реализации методов фаззинга рекомендуем использовать эксплойты,
работа которых предусматривает реализацию метода динамического
символьного выполнения. Программой выявляются не эксплуатируемые
ошибки (деление на 0, разыменование нулевого указателя). Как известно, во
время анализа аварийных завершений производится оценка состояния
регистров, стеков вызовов, памяти в момент срабатывания. В отношении этого
состояния применяются правила, позволяющие описать класс аварийного
завершения.
Анализ аварийных завершений создаст возможность специалистам ОАО
Аурат исключить вырабатываемую процессором инструкцию по доступу,
адресу, срабатыванию защиты. При этом каждый класс будет иметь ранг не
ниже чем вероятность, вызвавшую уязвимость или ошибку в программном
коде.
Рекомендуем каждый класс включить в одну из групп: эксплуатируемая,
возможно эксплуатируемая, не эксплуатируемая и недостаточно изученная. В
последний класс попадут аварийные завершения, анализ которых не позволяет
получить достаточную информацию. Одному аварийному завершению может
соответствовать только несколько классов.
Предложенный инструмент можно реализовать для программного
обеспечения, работающего под управлением операционных систем Windows,
Linux. Высокая скорость будет достигаться за счёт проведения анализа кода в
момент аварийного завершения программы.
Улучшить реализацию методов фаззинга позволит автоматическая
генерация эксплойтов. В результате этого специалисты компании ОАО Аурат
смогут получить входные данные, активизирующие существующие уязвимости
73
в программном коде. Таким образом, метод позволит исследовать аргументы
командной строки, файлов, переменных окружения.
Операции по символьным значениям будут представлены в виде формул.
При этом каждое ветвление в программе будет определяться символьными
данными, добавлять ограничения в общую систему.
Сформированное ограничение будет называться предикатом пути,
описывающим процесс выполнения программы. Если этот набор ограничений
предоставить на вход SMT-решателя, то в результате будет сформирован набор
ограничений.
Для успешного исключения уязвимости рекомендуем сформировать
набор дополнительных ограничений, поскольку формализация уязвимости
является сложным процессом.
Предложенный метод для повышения анализа качества программного
обеспечения ОАО Аурат приведён на рисунке 16.
Рисунок 16 – Предложенный метод для повышения анализа качества
программного обеспечения ОАО Аурат
Как видно из рисунка 16, в этом случае если программное обеспечение
произвело аварийное завершение, то будет реализован метод предварительной
классификации дефектов. Полученные результаты будут отправлены в систему
автоматической генерации эксплойта, включающей определенный набор
74
алгоритмов. После этого будет формироваться эксплойт, и осуществляться
проверка его работоспособности.
Анализ аварийных завершений позволит специалистам ОАО Аурат
осуществлять предварительную классификацию ошибок, фильтровать не
эксплуатируемые дефекты и тем самым повысить качество программного
обеспечения. Включая в механизм оценки качества программного кода этап
предварительной классификации, позволит исключить ошибки и количество
аварийных завершений.
Для реализации метода предварительной классификации рекомендуем
специалистам ОАО Аурат переработать группы и ранги классов аварийных
завершений. Поскольку реализация инструмента не учитывает некоторые виды
аварийных завершений, то во время работы программного обеспечения в
качестве классов аварийных завершения рекомендуем использовать в случаи
переполнения буфера, срабатывания ложных защитных механизмов.
Набор автоматической генерации эксплойтов позволит производить
проверку по бинарным трассам программ. В этом случае будет строиться
предикат пути от точки получения входных данных до точки срабатывания.
Также будет добавляться ограничение на указатель доступ которому не вызовет
исключения. В качестве примера такого адреса можно привести адрес секции
данных анализируемого исполняемого файла. Результатом будет являться
набор входных данных, который не будет вызывать срабатывание исключений.
После этого сформированные данные будут подвергаться предварительной
классификации и в этом случае возможно три случая:
- когда аварийное завершение относится к эксплуатируемым. Например,
переход по неправильному адресу. В этом случае будет осуществляться
генерация эксплойта с учетом предыдущих ограничений в указателе;
- если срабатывает исключение при доступе к другому указателю. В этом
случае процесс исправления указателя будет повторяться;
- если исправления относится к классу не эксплуатируемых.
75
Для тестирования предложенного метода была использована программа
gbd_exploitable, которая позволяет автоматически анализировать бинарный код.
Для проверки работоспособности применялся эмулятор QEMU, а для
получения набора аварийных завершений применялся фаззер утилит и
дистрибутив Debian 6.0.
В результате фаззинга было обнаружено 274 приложения, в которых
имеются входные данные, приводящие к аварийному завершению. Для этих
приложений производилась оценка качества программного обеспечения, и
полученные результаты приведены в таблице 7.
Таблица 7 – Полученные результаты предварительной классификации
Аварийные завершения
Класс аварийных завершений
Количество
1. Эксплуатируемые
Исключение в случае получения доступа к
памяти, адрес которой совпадает со счетчиком
команд
13
2. Возможно
эксплуатируемые
Возможно переполнение буфера
23
3. Недостаточно
изученные
Выявлено нарушение доступа
238
Как видно из таблицы 7, достаточно много было выявлено неизученных
аварийных завершений.
Предварительная классификация дефектов позволит специалистам ОАО
Аурат существенно сократить время на оценку качества программного
обеспечения исключения дефектов.
3.2. Предложения по внедрению динамического метода для исключения
критических ошибок и уязвимостей при автоматизации процессов
качества программного обеспечения
Также ОАО «Аурат» предлагаем применять динамический анализ для
регенерации входных данных для определения критических ошибок и
уязвимостей в программах. Для проведения динамического анализа
рекомендуем использовать программу Avalanche, которая является
76
инструментом, позволяющим обнаруживать программные дефекты на основе
динамического анализа качества программного продукта.
Программу Avalanche рекомендуем интегрировать с программой Valgrind
и инструментами проверки выполнимости ограничений STP.
В результате такого анализа можно получить набор входных данных, при
которых в программном коде возникает ошибка или набор тестовых данных,
позволяющих обойти ранее непроверенные фрагменты кода [34, c.46].
Таким образом, используя тестовый набор данных, программа Avalanche
позволит специалистам ИТ-отдела ОАО «Аурат» реализовать методы
динамического анализа для оценки качества программного кода, обнаруживать
ошибки и работает в полностью автоматическом режиме без вмешательства
тестировщика или программиста.
Преимуществами внедрения программы Avalanche в ОАО «Аурат»
являются:
- динамический анализ оценки качества ПО производится во время
работы программного обеспечения. При этом для запуска программы
используются некоторые входные данные;
- динамический анализ позволяет обнаруживать дефекты в различных
частях программного кода;
- в большинстве случаев появление ложных срабатываний исключено,
поскольку обнаруженные ошибки происходят в момент работы программного
обеспечения.
В случае динамического анализа входные данные должны быть выбраны
из наибольшего покрытия исполняемого кода.
Программа Avalanche реализует методы проведения динамического
анализа для поиска ошибок в программном обеспечении и их воспроизведения.
Сущностью этих методов является введение символических или помеченных
данных, получаемых программой из внешнего источника.
На следующем этапе выполняется сбор информации во всех помеченных
данных. Эта информация записывается в виде ограничений. Нахождение
77
значений помеченных данных, делающих эти ограничения выполненными,
указывает на возможность возникновения ошибки в программе.
Рассмотрим работу программы Avalanche, которая реализует подобный
подход при интеграции с программой Valgrind и инструментами проверки
выполнимости ограничений STP.
Предлагаем в состав среды Avalanche включить 2 модуля расширения
Valgrind, Tracegrind и Covgrind, инструмент для проверки выполнимости
ограничений STP и управляющий модуль. Предлагаемая архитектура среды
Avalanche приведена на рисунке 17.
Рисунок 17 – Предлагаемая архитектура среды Avalanche
Модуль расширения Tracegrind будет производить динамическое
отслеживание потока данных в программном коде, собирать условия для
обхода не пройденных частей и срабатывания опасных операций. Эти условия
при помощи управляющего модуля будут передаваться на STP для
исследования их выполнимости.
Если какое-то из условий будет выполнено, то STP определит те значения
входящих переменных, которые обращают условия в истину. В случае
выполнимости условий для срабатывания опасных операций программа
78
запускается с помощью управляющего модуля повторно с определенным
входным файлом для подтверждения найденной ошибки.
Выполнимые условия для обхода не пройденных частей программы
позволят определить набор возможных входных файлов для новых запусков
программы.
Таким образом, после каждого запуска программы инструмент STP
автоматически генерирует различные входные файлы для последующих
запусков анализа. После этого будет выбираться множество значений входных
данных, то есть в первую очередь, обрабатываться входные данные, на которых
наиболее вероятно возникают ошибки.
Для решения задачи будет применяться эвристическая метрика,
позволяющая определить количество не обойденных базовых блоков. Для
реализации этой метрики будет применяться программа Valgrind.
Для измерения значений эвристики рекомендуем специалистам ОАО
«Аурат» использовать компонент Covgrind, в функции которого входит
фиксация возможных ошибок выполнения. Компонент Covgrind является
легковесным модулем и позволит получать входные файлы из набора данных.
Программа Tracegrind будет отслеживать поток помеченных данных,
составлять условия, характеризующие возможность выполнения переходов или
каких-либо потенциально опасных операций. Среди потенциально опасных
операций следует выделить ошибки в программном коде.
Для составления условий с целью их последующей проверки с помощью
STP для каждой из инструкций промежуточного представления Valgrind
оперирует с помеченными данными и переводит их во входную декларацию
инструмента STP.
Рассмотрим принципы такого перевода. Перевод осуществляется во
время выполнения программного кода, с помощью динамического инструмента
Tracegrind. Результатом работы является получение двух трассировок.
Каждая трассировка представлена в виде текстового файла, включающего
последовательность декларации для STP. Содержимое транс во многом
79
совпадает, отличием является то, что в первую трассировку попадают условия
для проверки возможности обхода ранее не пройденных частей программы, а
во вторую условия для проверки возможности возникновения ошибок при
выполнении опасных операций деления и обращения к памяти. Трассы
разбиваются управляющим модулем на отдельные запросы STP.
Входной файл, регистры в адресном пространстве будут представлены в
виде массива STP:
memory_1: Array Bitvector(32) of Bitvector(8)= memory_0 with
[0hex04057000]:=file_input_dot_txt[0hex00000000];
В данном случае младшим адресом записываются младшие байты из
переменной t22, которые получаются на основании выполнения операции
выборки по соответствующим битам. В случае чтения происходит обратный
процесс. Так, при обработке инструкции t2, регистр 0 включает помеченное
значение. Далее запись массива STP будет иметь следующий вид:
memory_717: Array Bitvector(32) of Bitvector(8)= memory_716 with
[0hexbec91560]:=t_40139a0_0_0_22[7:0];
memory_718: Array Bitvector(32) of Bitvector(8)= memory_717 with
[0hexbec91561]:=t_40139a0_0_0_22[15:8];
memory_719: Array Bitvector(32) of Bitvector(8)= memory_718 with
[0hexbec91562]:=t_40139a0_0_0_22[23:16];
memory_720: Array Bitvector(32) of Bitvector(8)= memory_719 with
[0hexbec91563]:=t_40139a0_0_0_22[31:24];
Массивы, определяющие адресное пространство и входной файл будут
индексироваться и тем самым формировать массив регистров. Декларация для
массива памяти и регистров имеет вид:
memory_0: Array Bitvector(32) of Bitvector(8);
80
registers_0: Array Bitvector(8) of Bitvector(8);
Аналогично производится объявление и массива моделирующего
входной файл, но в его названии записывается имя файла (input.txt):
file_input_dot_txt: Array Bitvector(32) of Bitvector(8);
Моделирование временных переменных битовыми векторами
производится заданием их размерности 1, 8, 16, 32 или 64. В наименовании
переменной с синтаксисом STP должны быть указаны уникальные имена,
использующие адрес базового блока, которому принадлежит переменная. При
этом номер переменной в блоке и номер текущего посещения блока имеет
следующий вид:
t_409f9d8_59_2: Bitvector(8);
Данная декларация соответствует 50-однобайтовой переменной из
базового блока с начальным адресом 409f9d8. Причём декларация может быть
создана во время выполнения соответствующего базового блока.
Для создания декларации для системных вызовов, при перехвате вызовов
read и map создается набор деклараций, в которых отражается фактор
«равенство значений», прочитанных из файла по содержимому памяти.
Эта декларация моделирует чтение первого файла и файла input.txt в
ячейку памяти с адресом 0x04057000.
В общем случае, каждый из вызовов приводит к появлению цепочки
таких декларации по прочитанной информации. Декларации для инструкций
оперирующей с помеченными данными моделируется аналогично. Например,
для инструкции чтения из памяти: t17 = Ldle:I8(t15), в переменную t17
загружается 1 байт по адресу, отраженному в переменной t15. При этом ячейка,
поэтому адресу включает помеченные значения и формируется декларация:
81
Assert (t_40d1ff8_15_0=0hex000000000);
Query(false);
Если переменная t15 помечена, то трассировка с опасными операциями
также добавляется в декларацию, отражающую условия равенства t15 = 0, а
также синтаксическое указание STP для проверки выполнимости.
Наибольшую сложность представляют инструкции, считывающие или
записывающие сразу несколько байт.
Если выполнение дошло до инструкции условного перехода, то условие
его определяется от помеченной переменной. В зависимости от выполнения
или невыполнения условия создаётся декларация, в которой отражается факт
истинности или ложности этой переменной. Кроме того, в трассу переходов
также добавляется указание кивории.
Инструкция не произошедшего условного перехода приведет к созданию
следующей декларации:
Assert (t_40d3cab_3_0=0bin0);
Query(false);
Управляющий модуль будет позволять специалистам ОАО «Аурат»
связать компоненты Avalanche.
К его функциям будет относиться:
- координация взаимодействия между процессами остальных
компонентов;
- управление обходом дерева условных переходов.
После завершения работы модуля Tracegrind, управляющий модуль будет
осуществлять разбор двух трас.
Содержание файлов trace.log и dangertrace.log управляющего модуля
приведено в таблице 8.