«И невозможное возможно»: превращаем черный ящик в белый с помощью бинарного анализа

[third112]

Спасибо. Интересно.

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

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

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

И о Вашем подходе. Есть ли оценки Вашего метода типа: N байт кода — T время анализа, N2 байт кода — T2 время анализа? Не будет ли здесь крутой экспоненты?

[yaleksar]

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

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

[third112]

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

Можно ли утверждать, что если язык сложен для анализа, то:
— он хуже, чем более простой, т.к. затрудняет поиск уязвимости;
— он хуже, чем более простой, т.к. чем сложнее генератор кода — тем больше возможно в нем багов;
— он лучше, чем более простой, т.к. сложнее взломать исполняемый код?

Слышал мнение, что трансляция на эзотерические ЯП или для эмулятора машины Тьюринга усложняет анализ и повышает защиту. Ваше мнение?

[yaleksar]

Тут надо определиться с понятием «сложен для анализа». Сложность зависит в том числе от применяемых алгоритмов, а алгоритмы у разных анализаторов могут быть разные. Алгоритмы можно подстроить под конкретные язык, однако даже на одном языке можно писать код по-разному — сложнее или проще. Чем запутаннее программа, тем, потенциально, сложнее искать в ней уязвимости (опять же, в зависимости от метода). И тем сложнее восстановить конструкции исходного кода.

[qw1]

Мы проводили анализ своим инструментом одной из кодовых баз линукса

Какая задача при этом решалась?

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

2. Найти уязвимости в коде? Но, если считать, что это линукс, код скомпилирован из открытых репозиториев, и логичнее анализировать сразу исходники (которые уже и так стократно проанализированы стандартными инструментами).

1+2. Найти вставки кода, отсутствующие в репозитории, и найти в них уязвимости/ошибки. Такая задача сложная для авто-анализа, потому что робот не понимает суть внесённых изменений, поэтому не сможет определить, корректны ли изменения. И не проще ли попросить патчи к исходникам (лицензия это позволяет, да и автор кода, скорее всего, заинтересован в независимой проверке).

[yaleksar]

Безусловно, в данном случае логичнее анализировать исходные коды. Проводилось тестирование инструмента, обнаруживались уязвимости и закладки — то, что ищет инструмент.

[rboots]

Напомнило картинку «Как рисовать сову», исходного кода у нас часто нет, поэтому будем статически анализировать бинарный. Какими методами? Какими инструментами? Жду продолжения с подробностями.

[yaleksar]

Про методы и инструменты в статье описано — мы восстанавливаем модель кода, чаще всего это CFG (и описаны основные трудности восстановления), и далее применяем классические методы статического анализа — они, например, описаны в другой нашей статье. Можно описывать в деталях конкретные технические задачи — возможно, мы напишем несколько статей на эту тему.