С фокусом на безопасность приложений. Включать DAST в процессы стоит разумно и постепенно

С фокусом на безопасность приложений. Включать DAST в процессы стоит разумно и постепенно

Если вы интересуетесь темой безопасной разработки, то, наверняка читали прошлый выпуск РБПО, посвящённый статическим анализаторам. Сегодня мы поговорим о следующей практике безопасной разработки — динамическом анализе кода (DAST). В статье сосредоточусь на санитайзерах (sanitizers), подклассе инструментов динамического анализа в инструментарии С/С++ разработчиков.

СУТЬ ДЕЛА

Так что же такое динамический анализ и чем он отличается от статического? В первую очередь это процесс тестирования уже скомпилированного кода (либо его частей) в динамике (во время исполнения). Как это происходит? Создаём специальную «санитизированную» сборку с помощью всего лишь дополнительных опций компилятора (-fsanitize=). Такая сборка будет содержать дополнительную инструментацию — некие универсальные проверки, которые будут отрабатывать в ходе выполнения приложения. Тестирование подготовленной сборки и есть процесс динамического анализа.

ПРОВЕРКИ

Сразу становится интересным: какие могут быть проверки, которые не зависят от задач и позволяют санитайзерам быть полезными и для hello_world, и для условного SAP. Это проверки некоторых низкоуровневых инвариантов, нарушение которых приводит к серьёзным ошибкам. И, поскольку мы говорим о безопасном программировании, то речь об ошибках, которые могут использовать атакующие. Например, санитайзер встроит проверку, что к освобождённой памяти не будет обращения (защищая от UAF — use-after-free). Или предотвратит обращение за границу массива на стеке (OOB — out-of-bound). Также можно проверить на утечки, работу с памятью, надёжность многопоточной работы, отсутствие неопределённого поведения и другое. С помощью опций компилятора можно настроить не только объём проверок, но и поведение программы в случае срабатывания. В зависимости от способа использования динамического анализа в вашей компании разные варианты реакций могут быть полезны — от автоматического оповещения SOC до тихого подавления или рестарта приложения.

О СКРЫТЫХ ПРОБЛЕМАХ

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

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

Во-вторых, санитайзеры существенно замедляют работу: от 1,5 до 5–6 раз (!) в зависимости от объёма инструментации и характера нагрузки. А значит, многие тесты будут завершаться аварийно по time-out и разработчик будет злиться на краснеющий пайплайн. Когда пайплайны существенно замедлятся, разработчик ради стабильности и надёжности отключит динамический анализ для части тестов. От этого естественным образом снизится и полезность DAST, смотри пункт первый. Ну и при таких замедлениях и речи не идёт о том, чтобы включать динамический анализ в «релизе».

ДВЕ НОВОСТИ

Выходит, что полагаться только на динамический анализ нерационально? Да, но есть и хорошая новость. Некоторые проверки можно выполнить другими средствами. Например, чтобы обнаружить переполнение целочисленного знакового, можно использовать как динамический (-fsanitize=signed-integer-overflow), так и статический анализ. Статический анализ способен найти доступ к неинициализированной переменной. Однако статический анализ тоже раздражает разработчиков: для некоторых правил он выдаёт до 30% ложноположительных срабатываний. Случаются и ложноотрицательные, когда реальная проблема упускается.

Также некоторые проверки из арсенала динамического анализа можно выполнять через харденинги — другой вид инструментирования приложения. При скромном замедлении на 3–10% мы защитим приложение не только от ошибок разработчика, но и от намеренных повреждений при распространении атаки. Например, опция компилятора FORTIFY_SOURCE заменяет обращение к «небезопасным» функциям стандартной библиотеки дополнительными безопасными вставками и так позволяет избегать доступа вне диапазона (OOB). Аппаратный механизм MTE (memory tagging extension) c некоторой вероятностью защищает и от OOB и ошибок вида type confusion. Однако, этот механизм доступен не на всех аппаратных платформах.

УВЫ, НУЖЕН!

Так динамический анализ не нужен? Увы, нужен. Многие проверки не сделаешь иначе как санитайзерами. Это большая часть случаев undefined behavior, утечки памяти и нарушения memory safety разных сортов на «старых» аппаратных платформах или в виртуализованных окружениях. Фаззинговые тесты вообще бесполезны, если не настроены проверки инвариантов, и самая простая из них — инструментирование от санитайзеров, тот самый динамический анализ. Но включать DAST в процессы стоит разумно и постепенно. Я предлагаю идти по пирамиде: тесты, харденинг, статический анализ, динамический анализ, фаззинг (рис.). Так вы балансируете уровни пользы и затрат, настраивая проверки под себя для оптимального результата.

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