Уважаемые коллеги!

Сегодня, 16:15 (мск) на канале Общественного телевидения России выйдет передача серии "Очевидно.Вероятно", посвященная математике - "Математика вокруг нас".

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

Ведущий программы – Арутюн Аветисян, академик РАН, директор Института системного программирования им. В.П. Иванникова РАН.

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

Сегодня гость в студии – Николай Андреев, заведующий лабораторией популяризации и пропаганды математики Математического института им. В.А. Стеклова РАН.

Ссылка на прямой эфир ОТР: https://otr-online.ru/online/

https://otr-online.ru/programmy/ochevidno-veroyatno/anons-matematika-vokrug-nas-88285.html

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

Шкала «Критичность» разделяет все рекомендации на три основных уровня, каждый из которых отражает степень влияния ошибки на процесс и результаты испытаний:

- 3 (Недостаток высокого уровня критичности)
Прямое нарушение требований Методики ВУ и НДВ. Невыполнение требований, игнорирование ключевых процедур.

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

- 1 (Недостаток низкого уровня критичности)
Неэффективное выполнение испытаний, проведение испытаний с отклонениями от лучших практик РБПО.

- Рекомендация
Недостатки, которые не попадают под вышеуказанные категории, но могут быть полезны для улучшения процесса. Это могут быть предложения по оптимизации, уточнения или дополнительные рекомендации.

Методическая рекомендация № 2025-04-005 | Уровень критичности: 2

Область: Фаззинг-тестирование / Оценка критичности дефекта ПО

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

Описание: На рис. 1 представлена команда запуска фаззинг-тестирования командного интерпретатора bash, определенного экспертом как составляющего поверхности атаки, посредством передачи утилите на вход мутированных файлов-скриптов для последующих интерпретации и выполнения, для СЗИ типа А - "Операционная система общего пользования". На рис. 2 представлены статистики работы фаззера afl++, с помощью которого выполнялось фаззинг-тестирование. На рис. 3 представлен анализ результатов фаззинг-тестирования.

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

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

Рекомендации:

- выбирать цели фаззинг-тестирования исходя из реальной поверхности атаки на СЗИ с учетом наиболее вероятных сценариев воздействия нарушителя

- досконально анализировать все выявленные аварийные завершения и дефекты кода, являющиеся их причинами, и приводить в протоколах подробные разъяснения

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


Дополнительные информационные материалы:

- презентация Центра
- детекторы утилиты exploitable
- CASR - открытый отечественный улучшенный аналог exploitable

Коллеги, добавившиеся сегодня после Релавэкспо - презентации представлены в основном чате из семейства чатов РБПО-сообщества ФСТЭК России и ИСП РАН https://t.me/sdl_community/8171

Методическая рекомендация № 2025-04-006 | Уровень критичности: 3

Область: Фаззинг-тестирование

Тип недостатка: Низкая стабильность фаззера. Снижение эффективности генетического фаззинга.

Описание: На рис. 1 и рис. 2 представлены статистики работы фаззера afl++ (UI-представление и текстовые логи работы фаззера). Характеристика стабильности работы фаззера - параметр Stability - является значимо отличной от целевого (максимального) значения 100%.

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

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

- ошибки в инструментировании. Даже если программа выполняется по одному и тому же пути, ошибки в инструментировании могут привести к тому, что покрытие будет сохраняться недетерминированно

Значение параметра стабильности меньшее 95%, особенно в случае если отличие составляет не 2-3%, а 5% и более, является признаком сниженной эффективности фаззинг-процедуры, поскольку фаззер "перестает понимать" полезность смутированных сэмплов для открытия новых трасс выполнения - теряется (снижается) эффективность, достигаемая за счет генетического фаззинга (фаззинга с "обратной связью").

Рекомендации:

- анализировать значение стабильности фаззера, рассматривать его как один из важнейших показателей корректной организации фаззинг-тестирования

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

Дополнительные информационные материалы:

- описание стабильности в документации Crusher (прил. Г, на русском)
- описание подходов AFL к повышению стабильности (на английском)
- библиотека preeny, модуль derand

Методическая рекомендация № 2025-04-007 | Уровень критичности: 3

Область: Фаззинг-тестирование

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

Описание: На рис. 1 представлена статистика работы фаззера afl++ (UI-представление). Параметр last new find: none yet говорит о том, что за всё время работы фаззер не смог обнаружить ни одного нового пути выполнения программы.

При выполнении фаззинг-тестирования фаззер анализирует поведение программы, подавая на вход различные варианты тестовых данных (семплов). Основной метрикой эффективности работы фаззера afl++ является количество найденных уникальных путей выполнения исследуемой программы (объекта оценки). Если в процессе работы фаззера значение параметра last new find остается равным none yet, это указывает на то, что фаззер не может обнаружить ни одного нового пути выполнения программы. Полное отсутствие найденных путей выполнения программы является показателем неэффективности процедуры фаззинг-тестирования, так как основная цель фаззинг-тестирования заключается в исследовании различных сценариев работы программы для выявления потенциальных уязвимостей и ошибок. Такое тестирование не достигает своей цели и, как правило, не имеет практической ценности. В соответствии с требованиями Методики выявления уязвимостей и недекларированных возможностей, утвержденной ФСТЭК России 25 декабря 2020 года (далее - Методика ВУ НДВ), одним из критериев завершения фаззинг-тестирования является следующее условие:

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

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

Дополнительное предупреждение (odd, check syntax!) может свидетельствовать о проблемах с форматом или синтаксисом входных данных, которые передаются фаззеру.

Возможные причины отсутствия найденных путей:
- некорректный формат входных данных. Если семплы, передаваемые фаззеру, имеют неправильный формат или не соответствуют ожидаемому синтаксису, программа может игнорировать их или обрабатывать некорректно (например, если программа ожидает JSON, а входные данные содержат недопустимые символы или неверную структуру, фаззер не сможет обнаружить новые пути);

- ограниченность начального корпуса. Начальный набор тестовых данных (корпус) слишком мал или не покрывает достаточное количество состояний программы. Это ограничивает возможности фаззера по исследованию новых путей (например, если корпус содержит только один или несколько однотипных семплов, фаззер может не иметь достаточно разнообразных входных данных для анализа). На рис. 1 значение параметра corpus count равно 1 - это значит, что на вход исследуемой программе был передан всего один семпл, что противоречит требованиям Методики ВУ НДВ.

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

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

Рекомендации:

- необходимо анализировать значения last new finds и corpus count для оценки эффективности работы фаззера

Дополнительные информационные материалы:

- описание основных параметров UI-представления AFL++

Методическая рекомендация № 2025-05-008 | Уровень критичности: 2

Область: Статический анализ

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

Описание: На рис. 1-5 представлены размеченные предупреждения о потенциальных уязвимостях кода, полученные от статического анализатора. При этом результаты проведения разметки не содержат достаточного обоснования, позволяющего подтвердить корректность вынесенных вердиктов (Won't fix - истинное срабатывание, которое по тем или иным причинам исправлять нецелесообразно; False Positive - ложное срабатывание инструмента статического анализа).

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

Рекомендации:

- необходимо каждое размеченное предупреждение сопровождать индивидуальным комментарием, содержащим обоснование вынесенного вердикта

- при формировании комментариев необходимо избегать общих фраз, таких как «Не эксплуатируемо» или «Не применимо». Вместо этого необходимо приводить конкретные аргументы и обоснования (рис. 6-7 - пример корректной разметки)

- в случае, если срабатывание статического анализатора является False Positive - настоятельно рекомендуется заводить заявку (Issue) на исправление бага в трекер инструмента статического анализа. Также необходимо указать в комментарии к разметке ссылку на данную заявку, если трекер является публичным

Дополнительные информационные материалы:

- Инструкция по проведению разметки результатов статического анализа
- ГОСТ Р 71207-2024