WWW.KONF.X-PDF.RU
БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА - Авторефераты, диссертации, конференции
 

Pages:   || 2 | 3 | 4 |

«МОДЕЛЬ, АЛГОРИТМЫ И ПРОГРАММНЫЙ КОМПЛЕКС ДЛЯ АВТОМАТИЗИРОВАННОГО ПОИСКА УЯЗВИМОСТЕЙ В ИСПОЛНЯЕМОМ КОДЕ ...»

-- [ Страница 1 ] --

Министерство образования и наук

и Российской Федерации

ФГБОУ ВО Сибирский государственный аэрокосмический университет имени

академика М.Ф. Решетнева

(СибГАУ им. М.Ф. Решетнева)

На правах рукописи

Шудрак Максим Олегович

МОДЕЛЬ, АЛГОРИТМЫ И ПРОГРАММНЫЙ КОМПЛЕКС ДЛЯ

АВТОМАТИЗИРОВАННОГО ПОИСКА УЯЗВИМОСТЕЙ В

ИСПОЛНЯЕМОМ КОДЕ



Специальность 05.13.19 «Методы и системы защиты информации, информационная безопасность»

Диссертация на соискание ученой степени кандидата технических наук

Научный руководитель – кандидат технических наук, доцент Золотарев В.В.

Красноярск - 2015 Оглавление Введение

Глава 1. Проблемы и анализ существующих подходов к поиску уязвимостей в исполняемом коде

Введение в проблематику, основные термины и определения................ 14 1.1.

Классификация уязвимостей и ошибок программного обеспечения...... 19 1.2.

Модели и алгоритмы для поиска уязвимостей в исполняемом коде....... 27 1.3.

Обзор и сравнение существующих инструментальных средств для 1.4.

автоматизированного поиска уязвимостей в исполняемом коде

Выводы

1.5.

Глава 2. Модель и алгоритмы автоматизированного поиска уязвимостей в трассе программы с оценкой эффективности

2.1. Модель поиска уязвимостей в трассе программы

2.1.1. Алгоритм автоматизированного поиска уязвимостей в трассе................. 50

2.2. Методика трансляции исполняемого кода

2.2.1. Общий алгоритм частичной декомпиляции

2.2.2. Алгоритм интерпретации исполняемого кода

2.2.3. Алгоритм сборки

2.3. Алгоритм анализа помеченных данных

2.4. Метрики программного кода и их применение к задаче расчета эффективности тестирования

2.4.1. Алгоритм преобразования процедуры в граф

2.4.2. Описание метрик оценки сложности кода

2.5. Алгоритм расчета полноты и повышения эффективности тестирования... 74 2.5.1. Алгоритм расчёта количества достижимых вершин в программе........ 77

2.6. Выводы

Глава 3. Элементы системы автоматизированного поиска уязвимостей и повышения эффективности

3.1. Описание подсистемы расчета полноты и повышения эффективности систем тестирования

3.2. Модуль расчета сложности покрытия

3.3. Описание подсистемы автоматизированного поиска уязвимостей в трассе программы

3.3.1. Описание модуля частичной декомпиляции

3.3.2. Описание модуля анализа помеченных данных

3.3.3. Описание модуля детектирования уязвимостей

3.4. Выводы

Глава 4. Экспериментальная оценка эффективности комплекса.

................. 102

4.1. Общая схема взаимодействия подсистем в программном комплексе....... 102

4.2. Экспериментальная оценка эффективности метрик расчета сложности покрытия

4.3. Экспериментальная оценка эффективности подсистем и программного комплекса

4.4. Описание внедрений результатов диссертационной работы

4.5. Выводы

Заключение

Список сокращений и условных обозначений

Словарь терминов

Список литературы

Приложение 1. Список проанализированных приложений

Приложение 2. Статистический анализ частоты использования инструкций архитектуры x86 современными компиляторами

Приложение 3. Показатели эффективности используемых метрик............... 148 Приложение 4. Результаты сравнительного анализа эффективности подсистем автоматизированного поиска уязвимостей в трассе программы 152 Приложение 5. Результаты экспериментального анализа подсистемы расчета полноты и повышения эффективности тестирования

Приложение 6. Свидетельства о регистрации программы для ЭВМ............. 167 Приложение 7. Акты внедрения

Приложение 8. Дипломы и награды

Введение Актуальность Процесс безопасной разработки программного обеспечения сегодня регулируется множеством различных стандартов как в России, так и за рубежом. Несмотря на это разработчики и архитекторы продолжают допускать ошибки при разработке программных продуктов. Такие ошибки в свою очередь могут порождать серьезные проблемы, связанные с безопасностью информационных систем, в которых будут функционировать такие программные средства. В международной базе уязвимостей CVE (The Common Vulnerabilities and Exposures) ежедневно регистрируются десятки уязвимостей различного уровня опасности, в том числе и критические, которые могут приводить к компрометации информации на миллионах вычислительных устройств во всем мире.





Актуальность анализа исполняемого кода программного обеспечения (ПО) во многом обусловлена высоким уровнем распространения проприетарного ПО, исходный код которого представляет собой интеллектуальную собственность той или иной компании, которые как правило не заинтересованы в публикации или передаче своих разработок третьим лицам. Такая ситуация способствует появлению как случайных ошибок и уязвимостей, так и преднамеренно внесенных в код программных закладок. Помимо этого анализ исходного текста программы не позволяет обнаружить некоторые типы ошибок, которые могут быть связаны с особенностями компилятора или вовсе могут быть обнаружены только в рамках динамического анализа.

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

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

Степень проработки темы исследования Проблемой поиска уязвимостей в бинарном коде активно занимаются в следующих университетах: Беркли (Д. Сон, Л. Тао Вей, М. Пэйер, Ч. Хьёнсанг), Карнеги-Меллона (Д. Брумли, С. К. Ча, Т. Авгеринос, А. Реберт, Э. Шварц), Техаса (Р.

Вартел, В. Мохан, К. Гамлен, Ж. Лин), Калифорнии (М. Кова, В. Фельмештейгер), Колумбийском университете (А. Керомтис), а также в исследовательских лабораториях корпораций: Microsoft Research (П. Годефронд, М. Левин), IBM Research (Е.Р. Гарольд), Google (Д. Браунинг, Ж. Квин).

В РФ этой проблемой активно занимается Институт системного программирования РАН (Аветисян А.И., Падарян В.А). Проблема отказоустойчивости и безопасности программного обеспечения активно изучается на базе ФГУП НТЦ «Атлас» (Чижухин Г.Н., Бочкарева Ю.Г. и др.), на базе Сибирского государственного аэрокосмического университета им. М.Ф. Решетнева (Ковалев И.В., Антамошкин А.Н., Царев Р.Ю.). Также проблема изучалась в рамках кандидатских диссертационных работ на базе Санкт-Петербургского политехнического университета (Печенкин А.И.) и Южного федерального университета (Благодаренко А.В.).

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

количество детектируемых типов уязвимостей за промежуток времени;

количество ошибок первого и второго рода;

покрытие кода (отношение количества выполненных инструкций к их общему количеству в программе).

При этом в подавляющем большинстве случаев авторы не проводят низкоуровневый анализ выполненных инструкций, ограничиваясь количественной оценкой и не учитывая семантику исполняемого в программе кода. Кроме того, в качестве подсистемы детектирования уязвимостей авторы традиционно используют методику мониторинга приложения на предмет исключительных ситуаций в нем (выполнение некорректной инструкции, обращение по нулевому указателю или за пределы доступной памяти и т.п.). Такой подход не позволяет обнаружить целый класс уязвимостей в тех ситуациях, когда исключительная ситуация в приложении не возникает (переполнение нескольких байт буфера, чтение/запись по произвольному адресу в памяти и т.п.).

Целью данной работы является повышение эффективности автоматизированного поиска уязвимостей в исполняемом коде.

Для достижения указанной цели необходимо решить следующие задачи:

1. Провести критический анализ современных моделей, алгоритмов и их программных реализаций для поиска уязвимостей в исполняемом коде.

2. Разработать формальную модель автоматизированного поиска уязвимостей в трассе программы.

3. Разработать алгоритм автоматизированного поиска уязвимостей в трассе программы.

4. Разработать алгоритм расчета полноты и повышения эффективности тестирования.

5. Провести анализ эффективности разработанного алгоритма автоматизированного поиска уязвимостей в трассе программы.

6. Провести сравнительный анализ разработанного алгоритма расчета полноты и повышения эффективности тестирования с аналогами.

7. Реализовать предложенные алгоритмы в виде программного комплекса для экспериментальной оценки возможности детектирования ранее неизвестных уязвимостей в актуальных версиях программных продуктов.

Объектом исследования является исполняемый код программного обеспечения.

Предметом исследования являются инструменты поиска уязвимостей в исполняемом коде программного обеспечения.

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

Достоверность работы подтверждается результатами, полученными с использованием предлагаемого в работе подхода, и их сопоставлением с имеющимися современными теоретическими и экспериментальными данными, полученными другими авторами в этой области, а также обнаружением c помощью разработанного программного комплекса специально заложенных и ранее известных уязвимостей вместе с фактом обнаружения ранее неизвестных уязвимостей в широко распространенных программных продуктах, которые были официально подтверждены Internet System Consortium и Национальным институтом стандартов и технологий США.

Научная новизна

В диссертационной работе были разработаны:

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

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

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

Практическая значимость работы Разработанная в ходе работы модель, алгоритмы и программный комплекс могут быть использованы для выявления ошибок и уязвимостей в разрабатываемых и уже существующих программных продуктах, а также для анализа избыточного кода, вносимого вредоносными объектами.

Результаты работы по повышению эффективности поиска уязвимостей в программных продуктах были внедрены в рабочий процесс ООО «ГуардНет», ООО «ИнфоТраст», а также в образовательный процесс ФГБОУ ВО СибГАУ им М.Ф.

Решетнева для студентов следующих специальностей: 090105 «Комплексное обеспечение информационной безопасности», 090106 «Информационная безопасность телекоммуникационных систем», 090900.68 «Информационная безопасность». Элементы подсистемы декомпиляции бинарного кода были внедрены в проект по анализу бинарного кода в IBM Research Israel в 2014 г., а элементы подсистемы анализа ошибок были разработаны и внедрены в систему тестирования внутренних разработок компании Google в рамках программы поддержки проектов с открытым исходным кодом Google Summer of Code 2014.

Помимо этого в ходе экспериментального тестирования системы были найдены две ранее неизвестные критические уязвимости в видеофильтре LAV и в DNS

– сервере BIND9, за что получена официальная благодарность от международной организации Internet System Consortium с присвоением идентификатора в международной базе уязвимостей CVE-2013-4854.

Положения, выносимые на защиту:

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

Соответствует пункту 7 паспорта специальности 05.13.19. Анализ рисков нарушения информационной безопасности и уязвимости процессов переработки информации в информационных системах любого вида и области применения.

2. Программная реализация алгоритма автоматизированного поиска уязвимостей в трассе программы позволяет выполнять обнаружение уязвимостей, которые не приводят к исключительным ситуациям, что позволяет детектировать на 4типов уязвимостей больше существующих аналогов.

Соответствует пункту 7 паспорта специальности 05.13.19. Анализ рисков нарушения информационной безопасности и уязвимости процессов переработки информации в информационных системах любого вида и области применения.

3. Программная реализация алгоритма расчета полноты и повышения эффективности тестирования позволяет путём удаления и приоритизации тестовых данных снижать на 26-29% временные затраты, необходимые на поиск уязвимостей в анализируемой программе.

Соответствует пункту 10 паспорта специальности 05.13.19. Модели и методы оценки эффективности систем (комплексов) обеспечения информационной безопасности объектов защиты.

Апробация результатов работы Основные положения и результаты работы были опубликованы в 14 научных статьях и тезисах докладов. Из них 5 публикаций в журналах, входящих в перечень рецензируемых научных журналов и изданий, рекомендованных ВАК, 2 зарубежные статьи индексируются в международной базе Scopus. Результаты работы докладывались на семинарах кафедры БИТ СибГАУ им. М.Ф. Решетнева в 2013 и 2015 г., на семинаре кафедры КИБЭВС Томского государственного университета систем управления и радиоэлектроники в 2015 г., на научнотехническом семинаре группы научноEmerging Quality Technologies исследовательского подразделения IBM Research Израиль в 2014 г., а также на следующих конференциях:

1. Третья международная научная конференция «High performance computing HPC-UA 2013». Киев, Украина 04 - 08 октября 2013.

2. Международная научно – практическая конференция «Kaspersky CyberSecurity for the Next Generation 2013». Лондон, Великобритания 25 – 26 июня 2013.

3. Международная научная конференция «IEEE EuroCon 2013», Загреб, Хорватия 01- 04 июля 2013.

4. Региональный этап международной научно-практической конференции «Kaspersky CyberSecurity for the Next Generation. CIS round 2013» Ереван, Армения 20 – 22 февраля 2013.

5. Международный симпозиум «UKSim 6th European Symposium on Computer Modeling and Simulation». Валлетта, Мальта 14-16 ноября 2012.

6. II Всероссийская молодежная конференция «Перспектива – 2012». Таганрог. 24 - 28 июня 2012.

7. XVI и XIV Международные научные конференции «Решетневские чтения»

Красноярск. 11 – 14 ноября 2012 и 2014 гг.

8. XVII Всероссийская научно-техническая конференция студентов, аспирантов и молодых ученых «Научная сессия ТУСУР». Томск 16-18 мая 2012.

9. XI Всероссийский конкурс – конференция студентов и аспирантов по информационной безопасности «SibInfo – 2011». Томск 20 – 22 апреля 2011.

По теме работы было получено 6 свидетельств на регистрацию программы для ЭВМ и БД (см. приложение 6). Также результаты работы были отдельно отмечены дипломами и наградами (см. приложение 8).

Работа по теме диссертации (в качестве основного проекта под руководством автора диссертации) проводилась в рамках следующих грантов и контрактов:

грант РФФИ №14-07-31350 мол_а на 2013-2015 гг. «Разработка и апробация методик автоматизированной оценки надежности и безопасности современных программных продуктов в условии отсутствия исходных кодов».

грант Минобрнауки РФ №14.132.21.1365 на 2012-2013 гг. «Разработка программного комплекса декомпиляции бинарного кода».

контракт № ВГ_2011_6 ЗАО «Лаборатория Касперского» на 2010 - 2011 гг.

«Анализ запутывающих преобразований в машинном коде относительно вредоносных объектов».

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

Объем и структура работы Диссертация содержит: введение, 4 главы, заключение, список литературы (105 наименований) и 8 приложений. Общий объем диссертации составляет 183 страницы, включающих в себя 16 таблиц и 50 рисунков.

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

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

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

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

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

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

В четвертой главе выполняется апробация и экспериментальная оценка эффективности разработанного программного комплекса. Приводится общая схема работы системы и описывается взаимодействие между её компонентами.

В следующем разделе рассматривается вопрос эффективности предложенных ранее метрик оценки сложности для поиска уязвимых процедур в бинарном коде.

Описывается экспериментальный подход, который позволяет выявить наиболее эффективную метрику из предложенных.

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

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

В заключении приводятся основные результаты и выводы, полученные автором в ходе работы.

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

Глава 1. Проблемы и анализ существующих подходов для поиска уязвимостей в исполняемом коде Введение в проблематику, основные термины и определения 1.

1.

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

Такие ошибки в свою очередь могут порождать серьезные уязвимости, связанные с безопасностью разрабатываемого программного продукта и обрабатываемой им информации. Статистическое исследование международной базы уязвимостей CVE [1] за период с 1988 по 2014 показывает, что пик выявления уязвимостей пришёлся на 2006-2007 год, после чего наблюдался спад до 2011 года, а затем рост возобновился [2] (рисунок 1.1).

Количество уязвимостей

–  –  –

Причем необходимо отметить, что 72% всех уязвимостей за все годы наблюдения были обусловлены некорректной работой программы с памятью и ошибкой переполнения буфера (рисунок 1.2). Классификация и детальный анализ каждого типа ошибок и порождаемых ими уязвимостей будет приведен далее в этой главе.

–  –  –

Рисунок 1.2.

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

Рассмотрим вопрос природы возникновения уязвимостей в программном обеспечении. Как было отмечено выше, уязвимость является следствием ошибок, допущенных в процессе проектирования или разработки. Ошибки в программном обеспечении в свою очередь являются следствием развития современных информационных технологий в части увеличения объема, сложности и требований к масштабируемости программного кода. Достаточно показательным является статистическое исследование компании Coverity по 500 проприетарным программным продуктам, содержащим более 600 млн.

строк кода и 741 самому популярному продукту с открытым исходным кодом [3]. Так, по данным этого отчета, на 1000 строк кода в программном обеспечении с открытым исходным кодом приходится в среднем 0.72 ошибок, а для проприетарного эта цифра составляет в среднем 0.59 ошибки на тот же объем программного кода. Современный же программный продукт состоит из миллионов строк (например, ядро Linux содержит более 15 млн. строк кода) и может содержать десятки и сотни потенциальных ошибок, которые могут порождать уязвимости.

Актуальность анализа программ без исходного кода во многом обусловлена высоким уровнем распространения проприетарного ПО, исходный код которого представляет собой интеллектуальную собственность той или иной компании, которые как правило не заинтересованы в публикации или передачи своих разработок третьим лицам. Следовательно, такая ситуация способствует появлению как случайных ошибок и уязвимостей, так и преднамеренно внесенных в код недекларируемых возможностей. Это особенно актуально для РФ в связи с применением проприетарного ПО зарубежного производства для обработки и защиты информации ограниченного доступа (информация, доступ к которой ограничен федеральными законами). Для решения этой проблемы в нормативно – методических документах ФСТЭК, ФСБ и Минобороны России установлены требования и регламенты по обязательной сертификации программных средств на предмет отсутствия недекларируемых возможностей. Под сертификацией по требованиям безопасности информации понимают деятельность по подтверждению характеристик продукта, услуги или системы требованиям стандартов или иных нормативных документов по защите информации. Под недекларированными возможностями (НДВ) понимают функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации.

Необходимо отдельно отметить, что в РФ требования по анализу безопасности программного кода содержатся в ряде нормативно – методических документов [4,5]. Не будем подробно останавливаться на анализе нормативно – методической базы, а лишь отметим ряд ключевых моментов. Так в [6] устанавливается процедура обязательного прохождения сертификации средств обработки и защиты информации, обрабатывающих государственную тайну, а в [7] устанавливается процедура обязательного применения сертифицированных средств защиты информации для защиты персональных данных. В рамках сертификации предусмотрено проведение анализа программного кода на предмет отсутствия НДВ в испытательной лаборатории.

Стоит отметить, хотя верификация программы является в общем случае алгоритмически неразрешимой задачей [8], на практике активно применяются различные методики, наибольшую популярность среди которых получили методы статического и динамического тестирования ПО. Российские руководящие документы [5, 6] в рамках этого анализа предусматривают:

1. Контроль состава и содержания документации.

2. Контроль исходного состояния ПО.

3. Статический анализ исходных текстов программ, включающий в себя:

контроль полноты и отсутствия избыточности исходных текстов;

контроль соответствия исходных текстов по его объектному (загрузочному) коду;

контроль связей функциональных объектов по управлению;

контроль связей функциональных объектов по информации;

контроль информационных объектов;

контроль наличия заданных конструкций в исходных текстах;

формирование перечня маршрутов выполнения функциональных объектов;

анализ критических маршрутов выполнения функциональных объектов;

анализ алгоритма работы функциональных объектов на основе блоксхем, диаграмм и т. п., построенных по исходным текстам контролируемого ПО.

4. Динамический анализ исходных текстов программ, включающий в себя:

контроль выполнения функциональных объектов;

сопоставление фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа.

Вышеописанные методики позволяют проводить анализ ПО на НДВ при наличии исходного кода, однако их применение для анализа исполняемого кода ограничено. Также даже при наличии исходного кода существует проблема того, что преобразования, выполняемые компилятором и различными оптимизаторами, могут значительно изменить поведение приложения, сделав результаты аудита исходного кода недостоверными. Например, ниже С - функция memset выполняет перезапись пароля пользователя нулями в участок памяти, на который указывает переменная password:

memset(password, ‘\0’, len);

Для статического анализатора и даже для эксперта такой код будет вполне безопасным, однако компилятор при оптимизации может удалить вызов функции memset, тем самым оставив конфиденциальную информацию в куче. В зарубежной литературе эта проблема носит название «What You See Is Not What You eXecute» [9].

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

Существуют ситуации, когда есть информация о наличии ошибки или уязвимости в том или ином модуле ПО, но нет информации о конкретных участках кода и данных, для которых реализуется уязвимость. В таких ситуациях также применяется анализ исполняемого кода, который может занимать от нескольких часов до нескольких недель. Вопрос временных затрат на обнаружение ошибки имеет ключевое значение в том случае, когда ошибка влечёт за собой уязвимость и напрямую сказывается на защищенности информации, которую обрабатывает уязвимый продукт. Чем быстрее система тестирования сможет обнаружить уязвимость, тем быстрее появится возможность выпустить обновление и нейтрализовать угрозу.

Кроме этого, наличие неустранённой уязвимости может напрямую сказываться и на финансовых показателях компании, которая выполняет разработку уязвимого продукта. Так, в исследовании [10] авторы провели анализ снижения капитализации компании-разработчика ПО на фондовом рынке в зависимости от публикации информации об уязвимости в разрабатываемом этой компанией ПО. В результате авторы выявили следующую закономерность: в случае публикации информации о критической уязвимости, которая ранее не была устранена, компания теряет на рынке в среднем от 0.6% до 1.94% своей рыночной стоимости в зависимости от скорости выпуска обновления, нейтрализующего уязвимость (например, для Microsoft это составляет от 2.2 до 7.2 миллиардов долларов).

Классификация уязвимостей и ошибок программного обеспечения 1.2.

Дадим определения ключевым терминам, которые будут использоваться в настоящей работе (полный перечень приведен в словаре терминов):

Бинарный код (машинный код, исполняемый код) – код, исполняемый процессором.

Процедура в бинарном коде это группа инструкций для решения конкретной подзадачи, обладающая средствами получения управления из точки вызова задачи более высокого приоритета и возврата управления.

Согласно ГОСТам и другим нормативно – правовым документам РФ отдельного понятия для программной ошибки, программного дефекта или уязвимости в программном коде не существует, однако в [11] дефект или ошибка определяется как каждое отдельное несоответствие продукции установленным к ней требованиям. Помимо этого, этот же документ определяет термин тестирование.

Тестирование - деятельность, направленная на обнаружение дефектов в программном обеспечении [11].

Покрытие кода – мера, определяющаяся отношением количества выполненного кода в ходе тестирования к общему количеству кода в программе.

В [12] уязвимость информационной системы или брешь определяется как свойство информационной системы, обуславливающее возможность реализации угроз безопасности обрабатываемой в ней информации.

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

Защищаемая информация - информация, являющаяся предметом собственности и подлежащая защите в соответствии с требованиями правовых документов или требованиями, устанавливаемыми собственником информации [13].

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

Безопасность защищаемой информации - состояние защищенности информации, при котором обеспечены ее конфиденциальность, доступность и целостность [13].

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

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

Конфиденциальность обрабатываемой ПО информации – способность ПО обеспечивать состояние информации, при котором доступ к ней осуществляют только субъекты, имеющие на неё право.

Основой для терминов доступности, целостности и конфиденциальности информации, обрабатываемой ПО, послужили рекомендации по стандартизации «Информационные технологии. Основные термины и определения в области технической защиты информации» (Р 50.1.053-2005).

Правила разграничения доступа в ПО – совокупность правил, регламентирующих права доступа субъектов доступа к объектам доступа.

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

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

Уязвимости могут быть классифицированы с помощью различных подходов.

Dowd и другие в своей работе [14] выделили уязвимости в три базовых класса в зависимости от этапа разработки:

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

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

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

Однако этим классификация не ограничивается, существует множество работ, которые классифицируют уязвимости по их типу, источнику возникновения, потенциальной опасности и т.п. [15 - 17]. Ввиду обширности данной тематики, в рамках данной работы рассматриваются уязвимости, возникающие только при обработке пользовательских данных, передающихся в виде файла или через сетевой протокол в программных продуктах, реализованных на одном из компилируемых языков программирования (С/C++, Delphi, Pascal, Visual Basic и т.п). Приведем классификацию таких уязвимостей ниже. Для этого прежде всего необходимо описать существующие классы ошибок, так как они являются источником уязвимости.

а) Переполнение буфера. Переполнение кучи и стека.

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

Простым и показательным примером может служить вызов С функции strcpy без проверки длины входного буфера. Это позволяет атакующему контролировать память атакуемого процесса. Принципиальная схема атаки переполнения стека приведена на рисунке 1.3:

-----

–  –  –

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

Еще одним типом ошибки при работе с памятью является переполнение кучи.

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

б) Ошибки форматирования строк.

В стандартной библиотеке языка С существует класс функций printf (printf, snprintf и т.п), которые позволяют динамически создавать строки с помощью так называемых форматных спецификаторов (%d, %u, %s, %x, %n) и одного и более аргументов, которые содержат печатаемую информацию. Аргументы хранятся и возвращаются («выталкиваются») из стека, а форматные спецификаторы задают то, как аргументы должны быть отформатированы и добавлены (опционально) к тексту, тем самым формируя печатаемую строку:

–  –  –

Значение переменной answer будет продвинуто на стек вместе с кадром стека еще до того, как функция printf будет вызвана. Когда произойдёт вызов, printf вытолкнет значение, содержащееся на стеке, отформатирует его как целое число, сформирует строку и добавит к её концу полученное на предыдущем этапе число.

Если существует возможность вставить спецификатор %x в такую строку, то появится возможность читать данные из стека, вывода, а в некоторых случаях и записывать информацию в память.

г) Использование освобожденной памяти Данный класс ошибок возникает в тех случаях, когда выполняется обращение к памяти, которая была ранее освобождена. Типичным примером такого класса ошибок является использование памяти кучи уже после того, как был вызван системный вызов free для данного участка памяти.

д) Использование неинициализированной памяти Ошибки этого класса связаны с неправильным порядком инициализации и обращения к данным, выделенным в буфере. Таким образом данные используются еще до того как были инициализированы.

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

Рассмотрим ситуации, когда вышеописанные ошибки приводят к возникновению уязвимости в ПО. Уязвимость возникает в том случае, когда в результате ошибки происходит нарушение правил разграничения доступа к защищаемой информации, которая обрабатывается в ПО. Выше было отмечено, что правила разграничения доступа (ПРД) в ПО представляет собой совокупность правил, регла

–  –  –

Отдельно необходимо остановиться на понятии защищаемой информации. Согласно определению к защищаемой информации относится информация, подлежащая защите в соответствии с требованиями правовых документов или требованиями, устанавливаемыми собственником этой информации. На этапе разработки нет информации о том, какие конкретно защищаемые данные будут обрабатываться в программе, однако для выполнения поиска уязвимостей достаточно иметь адреса памяти, в которых эта информация будет храниться. В этом случае до начала тестирования достаточно сформировать и пометить тестовые защищаемые данные (которые будут обрабатываться в ПО как защищаемая информация), а затем проанализировать то, как эти данные будут обрабатываться, и сохранить информацию о том, какие участки памяти участвовали в этом процессе. Подробный алгоритм поиска участков памяти с защищаемой информацией приведен в разделе 2.4. Кроме того, к защищаемым участкам памяти для некоторых типов программ (в определенных разработчиком или владельцем программы ситуациях, например для сетевых приложений, где важна доступность предоставляемой информации) могут относиться те участки памяти, которые отвечают за управление программой и её бесперебойное функционирование.

Модели и алгоритмы для поиска уязвимостей в исполняемом коде 1.3.

Существует два базовых подхода к анализу безопасности бинарного кода: это статический и динамический анализ. Первый подход оперирует с программой без её исполнения, а второй соответственно предусматривает выполнение анализируемого кода, часто с использованием средств виртуализации.

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

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

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

1. Проблема разделения кода и данных.

2. Проблема замены абсолютных адресов относительными.

Рассмотрим каждую проблему более подробно. Статическое дизассемблирование бинарных файлов является алгоритмически неразрешимой задачей [18], так как использование инструкций с переменной длиной в современных микропроцессорных архитектурах не позволяет однозначно установить соответствие двоичного кода его ассемблированной инструкции. Рассмотрим подробно процесс трансляции ассемблерной инструкции в бинарный код.

Для трансляции сгенерированных ранее инструкций в бинарный код компилятор учитывает то, как процессор интерпретирует команды. Рассмотрим формат инструкций архитектуры x86 на рисунке 1.4:

–  –  –

Заметим, что кроме поля кода операции все остальные поля являются необязательными, т.е. в одних командах могут присутствовать, а в других – нет. Само поле кода занимает восемь бит и часто (но не всегда) имеет следующий формат, приведенный на рисунке 1.5:

–  –  –

Таким образом, для задания источника и приемника данных в опкоде используется 1 младший бит.

Рассмотрим остальные поля инструкции:

префиксы это специальное и необязательное однобайтное поле для изменения действия определенных команд;

поле mod R/M можно разделить на несколько подполей. Подполе mod определяет режим кодирования одного из операндов (регистр или данные из оперативной памяти по указанному адресу). Поле reg используется для кодирования регистра или в качестве расширения опкода (указывает номер инструкции в группе). Поле r/m кодирует регистр, который может быть либо операндом, либо указателем адреса в оперативной памяти, в зависимости от значения поля mod;

байт SIB (Scale, Index, Base) служит для кодирования адресов в памяти, вычисляемых как «множитель индекс + база»;

поля displacement и immediate необходимы для хранения значений констант, используемых в качестве операнда инструкции, либо при указании адреса одного из операндов.

Таким образом для компиляции необходимо сгенерировать значения тех полей, которые необходимо использовать в инструкции, и собрать в исполняемый код согласно формату, описанному на рисунке 1.4. Такая инструкция может быть сгенерирована несколькими способами, что и порождает сложности для однозначного дизассемблирования. Так ниже показано несколько вариантов записи одной и той же инструкции ADD AX, 0 для процессора с архитектурой x86:

(1) 0x05 0x00 (2) 0x83 0xC0 0x00 (3) 0x81 0xC3 0x00 0x00 В современном приложении исполняемый код распределяется по нескольким секциям исполняемого файла (пример для Windows PE и Linux ELF – файлов приведен на рисунке 1.6), также как и данные, создавая в свою очередь трудности для их однозначной идентификации при анализе.

Рисунок 1.6. Описание формата PE – файла Windows и ELF для Linux

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

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

выделение функций в потоке инструкций;

выявление параметров и возвращаемых значений;

восстановление структурных конструкций языка высокого уровня;

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

восстановление типов объектов языка высокого уровня, выявленных на предыдущем этапе [19].

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



Pages:   || 2 | 3 | 4 |
Похожие работы:

«Музалевская Екатерина Николаевна ЭКСПЕРИМЕНТАЛЬНОЕ ОБОСНОВАНИЕ ПРИМЕНЕНИЯ МАСЛА СЕМЯН АМАРАНТА ДЛЯ КОРРЕКЦИИ ОСЛОЖНЕНИЙ, ВЫЗЫВАЕМЫХ ИЗОНИАЗИДОМ 14.03.06 Фармакология, клиническая фармакология ДИССЕРТАЦИЯ на соискание ученой степени кандидата фармацевтических наук Научный руководитель: д.м.н., профессор Николаевский Владимир...»

«Сурчина Светлана Игоревна Проблема контроля над оборотом расщепляющихся материалов в мировой политике 23.00.04 Политические проблемы международных отношений, глобального и регионального развития Диссертация на соискание ученой степени кандидата...»

«Марченко Василий Сергеевич Методика оценки чрезвычайного локального загрязнения оксидами азота приземной воздушной среды вблизи автодорог 05.26.02 – безопасность в чрезвычайных ситуациях (транспорт) Диссертация на соискание учёной степени кандидата технических наук Научный руководитель: к.х.н., доцент Ложкина Ольга Владимировна Санкт-Петербург Оглавление Введение 1 Аналитический обзор...»









 
2016 www.konf.x-pdf.ru - «Бесплатная электронная библиотека - Авторефераты, диссертации, конференции»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.