Оценца времени фазинга

Поделитесь опытом, как можно примерно оценить время необходимое для фазинга в зависимости от размера входного файла?
На примере peach
и как можно это время минимизировать (к примеру: заменой одних сущностей для фазинга другими)
И ваще, кто чем фазит форматы фалов?

 

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

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

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

В основном пишу свой софт под конкретные задачи/форматы. Универсальные и "умные" фаззеры - это, как правило, много возни с заведомо сомнительным результатом.

 

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

А ты сравнивал результаты фазинга пичем и своим фазером на одинаковом задании?

Знакомый тоже ставит под сомнение фазинг фрэймворки

 

Тут видел объяву на работу в станкинформзащиту, там в требованиях умение пользоваться peach, sulley и еще чтото.
Видимо не так уж и безполезны фреймворки...

 

xssww2
Я присоединюсь к мнению Креша, лучший фаззер это свой, заточенный под определенную задачу фаззер =]
сори за офтоп

 

Имхо всякие ферймворки (Peach,sulley и т.д.) требуют хороших доработок.
Всякие новые эволючионные (Bitblaze) тоже ещё примерно в альфа версии.
Юзаю свои(описывающий протокол), либо старым дедовским методом(мутация единичек,ноликов).

 

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

Думаю, фреймворками пользуются сами разработчики, либо те, кому лень писать свой инструментарий. Фреймворки сами содержат в себе баги, а уж с таким, как peach, нужно ещё время, чтобы разобраться и полюбить его. Как и предыдущие комментаторы, пользуюсь своими инструментами. А требования работодателя, это видимо, чтобы как-то стандартизировать или отследить кпд работника.

 

Какие доработки нужны пичу, пару слов?
Для пича тоже описываеца формат, эфективность зависит от алгоритмов мутации, ты смотрел исходники пича? Сравнивал результат фазинга пича и своего фазера?

 

Хотелось бы конкретики)

Разработчики для чего-то их пишут, И по всей видимости ждут результата, наскока знаю peach, sulley бесплатны, так что им впаривать г нет смысла

Как и предыдущим задам вопрос, на практике ты сравнивал свои фазеры с фрэймворками?
Может еще быть проблема в неэффективном использовании фрэймворков, в описании формата для фазинга, поэтому и желаемых результатов нет

 

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

Хватит задавать абстрактные вопросы ни о чём: это на 100% зависит от конкретной задачи, описания которой ты не дал.

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

Привожу пример очень распространённой задачи, которая не решается с помощью Peach-а (без большого количества возни, во всяком случае).
----------------------
Формат файла представляет из себя следующее: есть более-менее константный заголовок, за которым следует произвольное количество блоков данных сложного формата с произвольной длинной. Блоки могут быть сжатыми LZH или ещё каким-то алго, а могут и не быть. Кроме того, они дополнены padding-ами до "круглого" размера (допустим, 100h).
Очевидно, что в данном случае более-менее приемлемым (при условии минимальных затрат на реализацию) будет следующий вариант:
- Заголовок нужно профаззить по шаблону.
- Блоки нужно профаззить мутационным генератором, исходные данные следует получать путём распаршивания эталонных файлов требуемого формата, которые лежат в указанной директории.
- Если блок сжатый - то фаззер на этапе генерации данных должен его расжать, выполнить модификацию данных и затем опять сжать.
- Опционально: реализацию алгоритма декомпрессии можно пофаззить отдельно in-memory фаззером.
- Padding, разумеется, нужно пропускать.

 

почему абстрактный, приминительно к тем задачам которые ты решал с помощью пича

работает как с байтами, так и c отдельными битами

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

описание заголовка peach pitом

я бы сдесь предпочел описать структуру блоков (до сжатия) с помощью пича, затем скормить мутатору

для этого в пиче есть <Action>...</Action> - расжать/сжать можно с помощью внешней программы, или заюзать встроенные (написать свой): Transformers

выделил бы в отдельную задачу

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

 

Через <Blob name="foo" valueType="hex" value="01 02 03 ... "/> ? Спасибо, нафик. Этим невозможно пользоваться.
Если прикрутят прозрачный импорт структур из С-шных заголовочных файлов и реализуют удобную работу с такими бинарными структурами на уровне Data Modeling-а - тогда можно будет подумать.

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

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

 

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

 

"Analysis of Mutation and Generation-Based Fuzzing" на примере этой статьи видно, что бОльшее покрытие кода дает генерирующий (шаблонный) фазинг
и тесткейсов меньше чем у мутационного, как отмечают авторы это частный случай
http://securityevaluators.com/files/papers/analysisfuzzing.pdf

 

чета хрень - не нашлось)))

 

Enjoy your Peach.
Кажется, я уже говорил, что не смотря на обманчивую простоту -- нужен опыт и common sense, что бы эффективно использовать этот фреймворк.

 

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

в общем случае, рассмотрим такую ситуацию:
pntrIncomingUserData db 500h dup (?) - данные поступающие от пользователя
pntrFunction dd ? - указатель на функцию который можно перезаписать
пускай в спецификации написано что входные данные имеют максимальный размер: 100h байт
как обнаружить данное уязвимое место?

как бы уязвимость есть, фаззер пускай сгенерирует по шаблону 100h*n где: n=[1..4] согласно его алгоритму мутации
т.е. получаем что фазер хоть и покрывает уязвимое место (копирование в буфер) но ошибку не обнаруживает n - достаточно мало
а что если буфер еще больше...

 

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

 

Покажи исходник/дизасм программы и исходник проекта Peach.
Насколько я могу судить - мутаторы Peach генерируют "мусорные" строки для триггеринга BoF-ов длинной порядка 1-2k. Классическое переполнение буфера на стеке или в куче, для которого нужно больше чем 1-2k символов -- это не очень типичный случай.

Да, ещё, как ты реализовал мониторинг исключений в процессе фаззинга? Уязвимый код может не вызывать падения программы, если, к примеру, в SEH-обработчике делается ExitThread (впрочем, это так же не очень типичный случай).

 

Про кучу не согласен

Настроенные исключения мониторяца самим windbg, как только оно происходит плагин !exploitable все логирует

По поводу taint-анализа, я склоняюсь больше к полуавтоматическому поиску уязвимостей, как описал выше.
На цц будет доклад одного чела про автоматизированный поиск уязвимостей с помощью таинт анализа. Как нибудь используешь/планируешь его использовать?