ЭКО — Экспертиза кода объекта оценки

Раздел методики: 4.4
Применимость для уровня доверия 4 (уровень контроля 4): базовое исследование (дополнительных усилений нет)
Кто проводит: испытательная лаборатория (совместно с разработчиком ОО при необходимости)

Задача исследования

Самостоятельное выявление методами ручного направленного анализа в модулях ОО:

• недостатков архитектуры
• уязвимостей конфигурации
• уязвимостей кода
• недекларированных возможностей (НДВ)

ЭКО — это ручной анализ участков исходного и восстановленного кода ОО.

Исходные данные

От разработчика ОО (п. 2.3 Методики):

• а) Документация на ОО: руководство пользователя, руководство администратора, руководство по безопасной установке и настройке
• б) ⭐ Исходный код ОО (основной объект ручного анализа)
• г) Дистрибутив ОО (для восстановления и анализа исполняемого кода)
• д) Результаты выполнения процессов разработки ОО по ГОСТ Р 56939-2024 в части, касающейся анализируемых модулей

Из предыдущих этапов:

• Сведения из ПОД.1: информация об инструментах и шагах инструментирования, иных модификациях бинарного/интерпретируемого/байт-кода в процессе сборки, способных исказить результаты статического анализа исходных кодов
• Список модулей ОО с участками кода на языках, не поддерживаемых используемым статическим анализатором, либо содержащих ассемблерные вставки (из материалов САО)
• Сведения о механизмах, препятствующих проведению динамического анализа (из ДАО.1, ДАО.2) — именно эти модули и участки кода подлежат обязательной ЭКО
• Исходные коды ОО (б) и исполняемый код ОО (г) — как непосредственный объект анализа

Требования к проведению исследования

Обязательный состав исследуемого кода

Испытательная лаборатория выполняет экспертизу участков исходного и восстановленного кода — ручной направленный анализ — в отношении как минимум:

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

2. Кода, не задействованного в ходе динамического анализа из-за встроенных в код механизмов, препятствующих динамическому анализу.

3. Кода, выполняющегося в контексте браузера (JavaScript, ActiveX, WebAssembly и другие).

4. Участков исходного кода, написанных с использованием языков программирования, не поддерживаемых используемым статическим анализатором.

5. Участков исходного кода, написанных на языке ассемблера.

Что НЕ требует ручного анализа

Не требуется выполнять ручной направленный анализ в отношении компонентов среды функционирования, входящих в состав поверхности атаки ОО, а именно:

• виртуальной машины интерпретируемых языков
• библиотек поддержки времени выполнения
• стандартных библиотек в составе виртуальной машины

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

Порядок действий при выявлении механизмов защиты от динамического анализа

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

При отказе разработчика:

• Испытательная лаборатория может самостоятельно разработать решения по снятию механизмов защиты от исследований.
• Если разработчик отказался снимать механизмы защиты или предлагаемые решения не позволяют провести исследования в полном объёме → делается вывод о невозможности дальнейших исследований.

Типы программных ошибок и НДВ для анализа

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

а) Использование потенциально опасных программных интерфейсов

б) Наличие заведомо некачественного программного кода:

• заведомо некорректное оформление исходного кода
• невыполнимые или тождественные условия
• не удалённые отладочные сообщения и другой код

в) Небезопасная загрузка библиотек

г) Некорректная обработка ошибок

д) Недостаточное ограничение прав доступа посторонних субъектов к временным файлам

е) Недостаточно полная проверка недопустимости присутствия во входных данных фрагментов программ на интерпретируемых языках (SQL-инъекции, XSS-атаки и другие типы атак)

ж) Некорректная обработка длин буферов с данными

з) Некорректная обработка ситуаций, когда вместо обычного файла ОО предоставляется именованный канал, символическая ссылка или иной файловый объект специального вида

и) Ненадлежащее обеспечение корректности совместного доступа к глобальным данным в параллельных вычислениях

к) Ненадлежащее хранение аутентификационных данных в оперативной или внешней памяти

л) Переполнение буферов

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

н) Предоставление пользователям избыточных полномочий

о) Утечки чувствительных данных в журнальные файлы

п) Утечки оперативной памяти, файловых дескрипторов, графических ресурсов и другие ошибки управления ресурсами

р) Целочисленные переполнения

с) Наличие неиспользуемых программных компонентов: функций, процедур, переменных, классов и других компонентов

т) Наличие бинарных вставок и кодировок, в которых данные вставки представлены

Требования к инструментам анализа

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

• определение количества файлов исходного кода, их расположения по каталогам
• типы файлов по языкам программирования
• размер и количество строк в файлах
• имена файлов
• поиск файлов в дереве исходных кодов

Для исследования логической структуры программы инструменты должны обеспечивать:

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

Для экспертизы восстановленного исполняемого кода:

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

При отсутствии инструментов с нужными возможностями для конкретного языка → допускается использование штатных утилит (ls, find, grep, cat, sort и других).

Дополнительная проверка

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

Фиксация перечня проверяемых ошибок

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

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

• CWE (Common Weakness Enumeration)
• Fortify Taxonomy: Software Security Errors
• Руководства и стандарты лучших практик: SEICERTC++ Coding Standard, The CERT Oracle Secure Coding Standard for Java и аналогичные

Устранение выявленных недостатков

Требуется выполнить действия, предписанные п. 2.7 Методики в отношении выявленных недостатков безопасности ОО (устранение возможно в ходе исследования; повторное исследование затронутых компонентов проводится в требуемом объёме).

Требования к результатам исследования

Результаты исследований фиксируются в материалах исследований в объёме, соответствующем п. 5.2 Методики.

Проверка артефактов результата

Формат для агента: артефакт считается принятым только при выполнении всех критериев; неприменимые пункты фиксируются с причиной.

Чек-лист проверки результатов перед отправкой

Формат: каждый пункт проверяется как выполнено / не выполнено / неприменимо.

Блок 1: Определение области анализа

• Определён перечень модулей с нестандартной модификацией кода при сборке — включены в ЭКО.
• Определён перечень модулей с механизмами, препятствующими динамическому анализу — включены в ЭКО.
• Определён перечень кода, выполняющегося в контексте браузера (JS, ActiveX, WebAssembly) — включён в ЭКО.
• Определён перечень участков кода на языках, не поддерживаемых статическим анализатором — включён в ЭКО.
• Определён перечень участков кода на языке ассемблера — включён в ЭКО.
• Компоненты среды выполнения (виртуальные машины, библиотеки поддержки) исключены из обязательного ручного анализа (задокументировано).

Блок 2: Инструменты анализа

• Инструменты для анализа физической структуры обеспечивают: счёт файлов, расположение по каталогам, типы файлов, размер, поиск в дереве кода.
• Инструменты для анализа логической структуры обеспечивают: определение сущностей, их иерархии, мест использования, связей между классами.
• Для восстановленного кода используется дизассемблер с итеративным дизассемблированием.
• При наличии: применяются инструменты визуализации потоков управления/данных или декомпиляторы.

Блок 3: Ручной анализ по типам ошибок

• Составлен и зафиксирован перечень проверяемых программных ошибок с критериями выявления.
• Проверены: потенциально опасные программные интерфейсы (п. а).
• Проверены: заведомо некачественный код, отладочные сообщения, невыполнимые условия (п. б).
• Проверены: небезопасная загрузка библиотек (п. в).
• Проверены: некорректная обработка ошибок (п. г).
• Проверены: права доступа к временным файлам (п. д).
• Проверены: SQL-инъекции, XSS и другие инъекции во входных данных (п. е).
• Проверены: обработка длин буферов (п. ж).
• Проверены: символические ссылки, именованные каналы, файловые объекты специального вида (п. з).
• Проверены: совместный доступ к глобальным данным в многопоточном коде (п. и).
• Проверены: хранение аутентификационных данных в памяти (п. к).
• Проверены: переполнения буферов (п. л).
• Проверены: избыточная функциональность до аутентификации (п. м).
• Проверены: избыточные полномочия пользователей (п. н).
• Проверены: утечки чувствительных данных в журналы (п. о).
• Проверены: утечки памяти, файловых дескрипторов, графических ресурсов (п. п).
• Проверены: целочисленные переполнения (п. р).
• Проверены: неиспользуемые программные компоненты (п. с).
• Проверены: бинарные вставки и кодировки (п. т).

Блок 4: Дополнительные проверки

• Выполнен контроль отсутствия использования сторонних программ при реализации ФБ ОО.
• Механизмы защиты от исследований (при наличии) разобраны совместно с разработчиком.
• При отказе разработчика от снятия механизмов защиты: зафиксировано принятое решение (продолжение/прекращение исследований).

Блок 5: Оформление результатов

• Результаты зафиксированы в материалах исследований (п. 5.2 Методики).
• Зафиксирован перечень проверяемых программных ошибок и критерии их выявления.
• Все выявленные недостатки безопасности задокументированы по форме таблицы 6 Методики.
• Для выявленных недостатков выполнены действия по п. 2.7 Методики (устранение, повторное исследование).

Задачи СИ по данному разделу

Рабочий перечень задач для Redmine: Перечень_задач_СИ_М3.md