Обеспечение интероперабельности анализаторов кода на основе унифицированного представления исходных текстов программ Марков Алексей Сергеевич к.т.н., с.н.с., CISSP Фадин Андрей Анатольевич CISSP ИТ-Стандарт Москва

План выступления Проблема безопасности ПО: основные понятия Методы анализа безопасности ПО Обеспечение унификации и интероперабельности анализаторов безопасности кода 2

Опыт работы испытательной лаборатории в сфере анализа кода Сертификационные испытания проведено более 500 сертификаций, проанализированы коды более 350 программных проектов на различных языках программирования (С/С++, Java, C#, Erlang, x86 ассемблер, JavaScript, Python, PHP и т.д.), в их числе есть операционные системы и коммуникационное оборудование, исследованы более 20 проектов зарубежных разработчиков Аудит безопасности кода (code security audit) выполнен для нескольких крупных проектов распределенных систем (веб-порталы, системы банк- клиент, системы электронных торгов)

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

ПРОБЛЕМА БЕЗОПАСНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Основные определения 5

Дефекты, изъяны и уязвимости программного обеспечения Дефект (Defect) Функциональность (поведение) Отказ работы Масштабируемость Сопровождение Архитектура Правила кодирования Дефект безопасности Изъян (Weakness по CWE) Уязвимость (Vulnerability) 6

Дефекты безопасности программного обеспечения Дефект – каждое отдельное несоответствие продукции установленным требованиям ГОСТ НАДЕЖНОСТЬ В ТЕХНИКЕ ОСНОВНЫЕ ПОНЯТИЯ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ Дефект безопасности ПО – ошибка в программном продукте, вследствие которой возможно нарушение целостности, доступности или конфиденциальности при функционировании продукта. 7

Недекларированная возможность Недекларированные возможности - функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации. Руководящий документ Защита от несанкционированного доступа к информации Часть 1. Программное обеспечение средств защиты информации Классификация по уровню контроля отсутствия недекларированных возможностей. 8

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

Скрытые каналы Скрытый канал (covert channel) – непредусмотренный разработчиком системы информационных технологий и автоматизированных систем коммуникационный канал, который может быть применен для нарушения политики безопасности. ГОСТ Р Защита информационных технологий и автоматизированных систем от угроз информационной безопасности реализуемых с использованием скрытых каналов. Часть 1. Общие положения. 10

Уязвимость информационной системы уязвимость (информационной системы); брешь - свойство информационной системы, обусловливающее возможность реализации угроз безопасности обрабатываемой в ней информации. ГОСТ Р Защита информации. Основные термины и определения Унифицированные системы документации. 11

Взаимосвязь понятий 12 Недекларированные возможности Уязвимости Дефекты безопасности программного обеспечения

РД. Защита от НСД к информации. ПО СЗИ. Классификация по уровню контроля отсутствия недекларированных возможностей (Гостехкомиссия России, 1999) Выполняемые проверки Уровень контроля Контроль состава и содержания документации Контроль исходного состояния+=== 3.1.Контроль отсутствия избыточности исходных текстов+++= 3.2.Контроль соответствия исходных текстов загрузочному коду+==+ 3.3.Контроль связей функциональных объектов по управлению-+== 3.4.Контроль связей функциональных объектов по информации-+== 3.5.Контроль информационных объектов-+=+ 3.6.Контроль наличия заданных конструкций Формирование перечня маршрутов выполнения ФО-++= 3.8.Анализ критических маршрутов выполнения ФО--+= 3.9.Анализ алгоритма работы на основе блок-схем, построенных по исходным текстам контролируемого ПО --+= 4.1.Контроль выполнения функциональных объектов-++= 4.2.Сопоставление фактических маршрутов и маршрутов, построенных в процессе проведения статического анализа -++=

Особенности руководящего документа: 4 уровня контроля отсутствия НДВ необходим для ПО, которое обрабатывает конфиденциальную, секретную, совершенно секретную информацию и информацию особой важности соответственно Этапы анализа (набор зависит от уровня контроля): Контроль состава и содержания документации Контроль исходного состояния ПО Фиксация контрольных сумм Поиск избыточности Статический анализ исходных текстов программ Связи между объектами Маршруты Графические материалы Динамический анализ исходных текстов программ Сопоставление маршрутов (статических и динамических) 14

Особенности руководящего документа: (2) В стандарте практически отсутствуют количественные характеристики анализа. Эксперт самостоятельно задает: необходимый уровень покрытия при динамическом анализе используемую базу уязвимостей допустимую меру избыточности кода и многие другие характеристики анализа 15

Недостатки РД: в документе есть ссылка на базу уязвимостей, но отсутствуют требования к ее содержанию и их описаниям большинство методов, используемых в документе «пришли» из теории надежности, в контексте анализа современных программных систем они часто трудновыполнимы из-за высокой сложности недостаточно четкие определения (маршрут, ветвь) статистика проведения аудитов исходных текстов показывает, что подавляющее большинство уязвимостей найдены с помощью сигнатурного поиска, а не структурного анализа 16

Подходы к разработке стандарта оценки защищенности ПО: зарубежный опыт Таксономии уязвимостей и дефектов OWASP Top Ten 10 самых больших угроз для веб-приложений Fortify Seven Pernicious Kingdoms 7 разрушительных "царств" компании Fortify MITRE Common Weaknesses Enumeration (CWE) Общая классификация изъянов ПО MITRE Common Vulnerabilities and Exposures (CVE) MITRE Common Attack Pattern Enumeration and Classification (CAPEC) Классификации Kaspersky Lab Symantec Corporation Mitre MAEC (на примере Conficker.B) 17

МЕТОДЫ АНАЛИЗА БЕЗОПАСНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Основные понятия 18

Подходы к анализу безопасности ПО 19 Аудит безопасности ПО (application security audit) Структурное тестирование (white-box testing) Пример: РД НДВ Статический анализ (static analysis) Анализ архитектуры системы Рецензирование, инспекция кода (code review, code inspection) Поиск потенциально опасных конструкций с помощью анализаторов кода Динамический анализ (dynamic analysis) Taint-mode analysis Контроль выполнения функциональных объектов (РД) Функциональное тестирование (black-box testing) Пример: РД НСД, РДВ Тестирование работы механизмов безопасности Фаззинг (fuzzing testing)

Статический анализ объекты исследования исходные тексты ПО исполняемый код ПО материалы производства ПО (отладочная информация, логи сборки, вывод внешних средств) параметры программного проекта (проектные файлы, манифесты) особенности подхода не требует запуска ПО ограниченный набор проверяемых свойств ПО (проблема «останова», теорема Райса) сложность анализа нелинейно возрастает с ростом объема анализируемого ПО 20

Области применения статического анализа компиляция, интерпретация исследование архитектуры (CASE-средства) и алгоритмов программы, автодокументирование форматирование кода вычисление программных метрик, общая оценка качества оптимизация, распараллеливание, профилировка преобразования (трансформации) программ, метапрограммирование обфускация/деобфускация программ обнаружение дефектов 21

Направления статического анализа Декомпозиция и анализ структуры ПО Анализ архитектуры системы Рецензирование, инспекции кода 1.2 Проверка стиля программирования, подсчет метрик Рецензирование, инспекции кода 1.3 Проверка свойств (ограничений) программы на моделях Поиск потенциальных дефектов ПО с помощью анализаторов кода 1.4 Поиск багов/дефектов по образцу (Сигнатурный анализ) Поиск потенциальных дефектов ПО с помощью анализаторов кода

Процесс статического анализа кода Предварительный обзор материалов проекта и формирование пакетов задач ПрепроцессингЛексический анализ Синтаксический анализ Семантический анализ Сигнатурный анализ Построение отчетов и последующие преобразования Отчеты по структуре Отчеты по сигнатурному анализу Экспорт моделей (e.g. UML) Преобразование (e.g. XMLVM)

Этапы построения модели программы 1) Исходный текст программы 2) Лексический анализ 24

Этапы построения модели программы 3) Синтаксический анализ. Дерево разбора 25

26 Выполняемые проверки Уровень контроля Контроль состава и содержания документации Контроль исходного состояния+=== 3.1.Контроль отсутствия избыточности исходных текстов+++= 3.2.Контроль соответствия исходных текстов загрузочному коду+==+ 3.3.Контроль связей функциональных объектов по управлению-+== 3.4.Контроль связей функциональных объектов по информации-+== 3.5.Контроль информационных объектов-+=+ 3.6.Контроль наличия заданных конструкций Формирование перечня маршрутов выполнения ФО-++= 3.8.Анализ критических маршрутов выполнения ФО--+= 3.9.Анализ алгоритма работы на основе блок-схем, построенных по исходным текстам контролируемого ПО --+= 4.1.Контроль выполнения функциональных объектов-++= 4.2.Сопоставление фактических маршрутов и маршрутов, построенных в процессе проведения статического анализа -++= РД. Защита от НСД к информации. ПО СЗИ. Классификация по уровню контроля отсутствия недекларированных возможностей (Гостехкомиссия России, 1999).

Этапы построения модели программы 4) Абстрактное дерево разбора (AST) 27

Граф потока управления (CFG) и граф зависимостей по данным (DFG) 28 1 int m(int x, int y) { 2 while (x > 10) { 3 x -= 10; // x = x - 10; 4 if (x == 10) { 5 break; 6 } 7 } 8 x = square(x); 9 if (y < 20 && x%2 == 0) { 10y += 20; // y = y + 20; 11 } 12 else { 13 y -= 20; // y = y - 20; 14 } 15 return 2*x + y; 16 }

Однократное статическое присваивание (SSA) 29

Абстрактный семантический граф 30

Сигнатурный анализ Происхождение термина «сигнатурный анализ» (signature analysis) диагностика электронных схем путем сопоставления входного и выходного сигнала метод анализа подчерка в графологии Сигнатурный анализ программного кода Поиск программных дефектов в исходных текстах или исполняемых модулях путем сопоставления фрагментов с образцами из базы данных шаблонов (сигнатур) уязвимостей 31

32 Выполняемые проверки Уровень контроля Контроль состава и содержания документации Контроль исходного состояния+=== 3.1.Контроль отсутствия избыточности исходных текстов+++= 3.2.Контроль соответствия исходных текстов загрузочному коду+==+ 3.3.Контроль связей функциональных объектов по управлению-+== 3.4.Контроль связей функциональных объектов по информации-+== 3.5.Контроль информационных объектов-+=+ 3.6.Контроль наличия заданных конструкций Формирование перечня маршрутов выполнения ФО-++= 3.8.Анализ критических маршрутов выполнения ФО--+= 3.9.Анализ алгоритма работы на основе блок-схем, построенных по исходным текстам контролируемого ПО --+= 4.1.Контроль выполнения функциональных объектов-++= 4.2.Сопоставление фактических маршрутов и маршрутов, построенных в процессе проведения статического анализа -++= Нормативная база применения метода сигнатурного анализа РД. Защита от НСД к информации. ПО СЗИ. Классификация по уровню контроля отсутствия недекларированных возможностей (Гостехкомиссия России, 1999).

Требования руководящего документа Для второго уровня контроля необходимо выполнять синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций. Для первого уровня контроля необходимо выполнять семантический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций. 33

Задачи, представления кода и методы статического анализа 34

Задачи, представления и методы статического анализа 35

ОБЕСПЕЧЕНИЕ УНИФИКАЦИИ И ИНТЕРОПЕРАБЕЛЬНОСТИ АНАЛИЗАТОРОВ БЕЗОПАСНОСТИ КОДА 36

Процесс статического анализа кода Предварительный обзор материалов проекта и формирование пакетов задач ПрепроцессингЛексический анализ Синтаксический анализ Семантический анализ Сигнатурный анализ Построение отчетов и последующие преобразования Отчеты по структуре Отчеты по сигнатурному анализу Экспорт моделей (e.g. UML) Преобразование (e.g. XMLVM)

Требования к стандартам в области представления кода Поддержка максимального числа языков и платформ программирования (в идеале: 4-5 поколений, от ассемблера до DSL языков) Структурированная форма, удобная для анализа и последующего преобразования Легкость реализации и адптации уже существующих парсеров языков 38

Существующие инициативы по стандартизации представления кода 3-address IR Java bytecode Microsoft CLR DIANA SUIF RTL of GCC compiler GIMPLE of GCC compiler LAST of the McCAT compiler TSRI IOM, JPGen and JTGEN OMG Meta Object Facility MOF

Примеры: LLVM (Low Level Virtual Machine) void f(int a, int b[10]) { x = } define %a_arg, i32* %b_arg) nounwind { ; make space for arg a and ptr to int (array arg b) %a = alloca i32 %b = alloca i32* ; store constant arguments into memory locations store i32 %a_arg, i32* %a store i32* %b_arg, i32** %b ;... can mess with args now... %t0 = add i32 33, 0 ; t0 = 33 store i32 %t0, i32* %a ; a = t0 %t1 = load i32* %a ; t1 = a; ret void }

Примеры: Parrot

Примеры: XMLVM

Примеры: OMG Group (ASTM, KDM)

НОВЫЙ ПОДХОД К СТАНДАРТИЗАЦИИ ПРЕДСТАВЛЕНИЯ КОДА Предложение ЗАО «НПО «Эшелон» 46

Состав структурного представления 47 Элементы языка Модуль Макросы Объект Атом Ссылка Выражение Управление

Состав структурного представления 48 Имя в кодеНеймспейсОписание code-common дефолтовый неймспейс для всего представления кода, по сути абстрактное синтаксическое дерево для всех языков. Мы исходим из того, что все схемы элементов из этого неймспейса больше меняться не будут code-language неймспейсы связанные с содержимым у всех конкретных языков программирования, возможно имеет смысл делать для целых групп языков, например ns_ecma, но пока ограничимся одним. В процессе развития модулей можно будет её дописывать и дорабатывать. code-analysis неймспейсы связанные с анализом кода, с ошибками обработки (парсинга), с семантикой элементов всё это тоже хранится в

Элементы программы Корневой элемент, символизирующий файл исходных текстов на каком-либо языке. Вставки на других языках оформляются отдельными модулями, т.е. модуль может содержать другие модули. Пример, язык Pascal: Элемент обозначает описание структурных единиц программы (функций, классов, интерфейсов, обработчиков прерываний, и т.п.), а также выделение памяти под них (создание экземпляров классов и встроенных типов) Пример, язык C++: неделимая единица языка, для которой сразу доступно её полное определение Примеры, язык C 49 Program Test_Program3; Class ABC{ }; 5, test string, void

Атрибуты - уникальный - идентификатор элемента используемый в языке - координаты элемента в файле - лексическое содержимое элемента - языкозависимые особенности элемента - исходный код элемента существуют три политики заполнения source - их должен поддерживать каждый парсер: помещать туда лишь тот код, что не удалось распарсить помещать туда весь код (удобно для отладки) не помещать туда кода ( в случае жестких политик по распространению исходников на объекте заказчика)

ссылка на object по его имени, указателю, ссылке и др. указания на объекты в других частях кода, например декларации функций без реализации Пример, язык Java: Конструкция с использованием встроенных или переопределенных операторов языка Пример, язык Java: Изменение потока выполнения программы: передача управления в другую область кода, вызовы функций, условные ветвления, циклы и т.п. Пример, язык Basic: 51 double pi = ; double l = 2*pi*R; double pi = ; double l = 2*pi*R; IF LEN(A$) = 0 THEN GOTO 90 Элементы программы (2)

Конструкции, не являющиеся непосредственной частью языка, как правило используемые утилитами сборки: команды препроцессора, директивы управления компилятором и т.п. Пример, язык C++ 52 #include Элементы программы (3)

Унификация представления конструкций языка 53 (объекты, ссылки) элементов на которые передается управление Вызов (C) Источники информации (объекты, ссылки, атомы) Вход (I) Приемники информации (объекты, ссылки, атомы) Выход (O) Вектор из трех наборов элементов представления языка

Пример представления кода 54 switch(a) { case y: printf(!); case o: printf(!); }; (meta:switch) (meta:unary) a (meta:case) (meta:unary) o (meta:function-call) (printf) (meta:case) (meta:unary) y (meta:function-call) (printf)

Пример реализации задачи Построить сигнатурный анализатор способный определять дефекты безопасности описанные на уровне внутрипроцедурного потока данных (data flow) с применением регулярных выражений 55

Фрагмент программы на языке PHP с потенциально реализуемой SQL- инъекцией содержимого cookies клиентского браузера в СУБД PostgreSQL

Виды необходимых сигнатур Для выявления типов элементов Типа «ссылка» Типа «литерал» Для выявления контекста элементов Источник данных Приемник данных Источник перехода Для выявления потенциально опасных операций (пример: pg_copy_to) Для выявления непроверенных источников данных (пример: _GET) 57

Выполнение внутрипроцедурного анализа Шаг 1: 1:(0,(_COOKIE),$id) Шаг 2: 2:(0, $id, $query) Шаг 3: 3:(pg_query, $query,$result) Шаг 4: 4:(pg_query, _COOKIE,$result) После шага 4 у нас срабатывают одновременно две сигнатуры критичных операций (получение данных из COOKIE и выполнение запроса к СУБД) и мы можем сигнализировать о наличии потенциально опасной конструкции: использование данных веденных от пользователя в SQL-запросах без предварительной фильтрации 58

Фрагмент программы преобразованный в форму CIO 59

Выводы по применению сигнатурного методов статического анализа Стандартизация в области взаимодействия между средствами: анализа, генерации, трансформации кода и построения моделей систем находится еще на очень ранней стадии Существует масса разнородных проектов Наиболее концептуально полны стандарты группы OMG, но они находятся на ранней стадии развития и ориентированы в большую очередь на моделирование бизнес-процессов и отображения их на код, а не на его анализ Проекты LLVM, Parrot технологически зрелые, но их промежуточное представление недостаточно структурировано Необходима разработка и апробация новых стандартов в этой области Наш проект - один из них 60

61 Контакты докладчика: Спасибо за внимание! Вопросы?