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

Да, tainting это крутая тема, только текущие реализации адско медленные, и для поиска багов , к примеру в браузерах просто неработают без дополнительных техник, наподобии slicing'a. Но slicing ведёт к ещё большим гемороям

 

Тупиковый путь, т.к. для больших приложений которые работают со входными данными сложной структуры -- это колоссальный объём ручной работы.

В проектах не использую по той причине, что все существующие на данный момент разработки в области taint analysis -- медленное, плохо интегрируемое со сторонними системами и крайне бажное г-но. В том числе и BitBlaze, про который будут рассказывать на СС. Основные причины подобной ситуации кроются, вероятно, в том, что пока что подобные разработки остаются уделом теоретиков из академических кругов, а не практиков vulnerability researching-a.
Разумеется, пользу taint analysis как технологии я не отрицаю, и более того -- веду собственные разработки в этом направлении. Пока что единственным приемлемым вариантом по соотношению между затратами на реализацию и эффективностью для практического применения мне видятся DBI движки (я в своих экспериментах перешел с PIN на DynamoRIO, чего и всем желаю).
Из публичных проектов, которые используют DBI для taint analysis могу отметить только BAP -- весьма правильный (на мой взгляд) фреймворк в плане идей, но с совершенно уё***ным их воплощением в коде (я собирал и тестировал BAP под Win32, попутно исправляв пачку критических багов, связанных с многопоточностью).
В моих задачах главная область применения taint analysis -- это fault analysis. С положительными результатами автоматизированного поиска уязвимостей у меня всё ок, а вот с анализом этих уязвимостей и разработкой, собственно, эксплойтов -- пока что дела обстоят немного грустно, т.к. всё это приходится делать руками, что при "промышленных" объёмах требует непозволительно много человекочасов.

 

Да, это одна из причин, но не главная.
Главная причина - чтобы реализовать систему taint analysis, которая будет находить уязвимости в реальных условиях(в современных веб-браузерах), требуются просто огромные человеческие ресурсы, так как для этого требуется эмулятор x86, внедрённый в него механизм taint propagation, и фактически эмуляция половины функционала операционной системы. Пока ребята из Berkley делали taint propagation для qemu версии 0.9.0, вышла уже qemu 0.12 где реализация эмуляции работала по совершенно другому принципу, да и Windows 7 вышла, а у них system info extractor работает для Win XP, и то через ж-у.А про ихний IL и говорить не хочется, это реально бажное г-но!

 

Cr4sh
Кстати, реализация taint propagation для DBI(Pin,DynamoRIO) - это просто титанический труд.
Видел в паблике только начальные реализации - распостранение на инструкции mov, только это маленькая часть, чтобы реализовать работающую систему taint propagation.Плюс к тому, есть ещё множества гемора, к примеру indirect taint propagation.

 

Есть и другие варианты, к примеру -- трансляция машинного кода в llvm-байткод, для x86 подобные работы ведутся в рамках проекта libcpu, но находятся они всё ещё на ранних стадиях разработки.

В моём случае это не слишком критично, т.к. "high level", типа возможностей указывать в качестве источника тейнтированных данных конкретный файл или сокеты -- не требуется. На начальном этапе вполне достаточно будет функционала типа "снимать taint начиная с такого-то аргумента такой-то инструкции по такому-то адресу". Хочется верить, что при подобных раскладах уход вектора исполнения в системные вызовы ядра не будет срывать тейнтинг.
Цели написать нечто, что будет само уязвимости искать -- я вообще не ставлю, пока что хочу что-то вроде "продвинутого" варианта !exploitable, который будет минимально затачиваться руками под внутренности конкретной исследуемой программы.

А что ещё делать, лол. На то, что в обозримом будущем удастся дождаться нормальной реализации в open source -- не хочется полагаться. Тем более, что "по дороге" в любом случае будут интересные и полезные промежуточные результаты.

Посмотри ещё BAP. Правда, там баг на баге.

[modnote=Great]перенес тему как ты просил[/modnote]

 

если фазинг (как класс) не помогает, что еще остается??? я не ставлю целью - решение массовой задачи поиска багов

Тоже занимаюсь, пишу расширение для windbg с последующим анализом в IDA (как писал выше)

как вариант

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

 

судя по этой статье:
http://cisscompany.com/publikacii-i-issledovaniya/bitblaze-–-budushhie-bezopasnosti-po.html
ну помогает в исследовании программ, ну строит трассы, ну оптимизирует, и еще много чего, но как с помощью нее находить уязвимости (кроме утечек данных)???
Bitblaze, BAP (как я понял из прочитанного) не оказывает влияние на ход выполнения программы, как фазер, он ток может облегчить поиск функций для работы фаззера
Или есть какие фаззер-плагины для этих фреймворков?

KLEE юзал?

 

Не будет такое работать на реальных приложениях из-за крайне низкой производительности debug api и прочего. Не забывай, что taint analysis имеет смысл только в том случае, если трассировка исследуемого приложения происходит по всем инструкциям всех исполняемых модулей режима пользователя. По этой причине в качестве трассировщика для задач taint analysis подходят только:
- DBI движки (PIN, DynamoRIO).
- Модифицированные виртуальные машины.
- (Возможно?) трассировщики на прерываниях работающие в Ring0, не использующие при этом debug capabilities предоставляемые самой операционной системой.

LLVM "as is" плохо подходит, т.к., повторюсь, нужен контроль над исполнением всего user mode кода, а не только кода исследуемого приложения, иначе уход вектора исполнения в какое-то API типа user32!StringCbCopyEx() будет сбивать тейнтинг.

С помощью BitBlaze/BAP/итд. как таковых -- никак. Но получаемую в ходе taint analysis информацию можно использовать как "обратную связь" с обычным мутационным генерирующим фаззером. Почитай, к примеру, про проект fuzzgrind.

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

 

xssww2
Приезжайте на CC и узнаете, как с помощью bitblaze находить уязвимости
Хотя Cr4sh уже всё рассказал, могу лишь поподробнее цепочку описать:
1.трасса с информацией о taint
2.трасса -> IL
3.IL -> STP/SMT
4.конкретная задача для STP/SMT, например, как нужно изменить данные, чтобы на conditional jmp по такому-то адресу, прыгнуть в другом направлении.
5.STP/SMT -> результат(входные данные следующей итерации) -> к первому пункту.
То есть поиск уязвимостей реализовывается через:
1.Покрытие графа
2.Различных сигнатур/задач для solver'ов

 

есть повод задумаца и рассмотреть по-подробней
так ты эту связку юзаешь?
помница ты писал "Юзаю свои(описывающий протокол), либо старым дедовским методом(мутация единичек,ноликов)."

 

xssww2

Тут следует различать, что используется для исследований, а то для получения реальных результатов.
для получения реальных результатов - описывающие фаззеры, простейшие bit-flipper'ы в купе с windbg/winappdbg, DBI(PIN + Pin tools).
Для исследований - Bitblaze(Vine+temu).

 

Я уже писал, что так называемые системы поиска уязвимостей "нового поколения"(основанные на taint analysis алгоритмах) адско медленные - это субъективное понятие.
Приведу пример, чтобы стало ясно, почему на данный момент это только прототип:
MS Word 2010 запускается примерно за 1 секунду(возьмём это как контстанту, хотя это зависит от тестовой машины).
Запуск MS Word 2010 под отладчиком(Windbg) увеличит это время минимально(я думаю, не более 0.01 секунды).
А запуск MS Word 2010 в temu, происходит за 20 минут - на мой взгляд, это просто напросто нерентабельно!
На данный момент, я нашёл лишь одно применение Bitblaze'a, где эта система даёт хоть какие-то результаты, но об этом будет рассказывать Александр Бажанюк на Chaos Construction.

 

Я так понял, как должно быть ,для одного сэмпла вордового документа происходит запуск ворда, дожидаемся отображения содержимого документа, после этого solver, спускаеца вниз по дереву ветвлений, для максимального покрытия кода, выбирает очередную вершину, и так для каждой вершины повторяем запуск ворда, получаеца просто ппц как медленно, так?
Распаралелить нельзя?

Но fuzzgrind както работает, в статье о нем пишут что и баги нашли
Ты его тестил?
Под венду есть форки?

Интересно канеш

 

Я пока эксперементирую, если как я задумал не получица, то делать не буду

Да, в моем случае будет проблема с COM/DCOM

А что с ней не так? у меня трэйсер ходит по апишкам

 

Только не solver, а алгоритм обхода графа, solver(STP/SMT etc) обрабатывают программу на своём языке для решения какой-либо задачи(разворачивание потока выполнения, как пример).
Да, очень и очень медленно. механизм snapshot'ов по идее должен тут сыграть роль волшебной палочки, но на практике этого не произшло

Можно.

Лично я - нет, тестил Александр Бажанюк.
Под винду форков по моей информации нету(так как он основан на множестве тулз, которые nix-only - valgrind к примеру).
Fuzzgrind - не вариант, так как требует исходников, и нацелен на OpenSource проекты.

 

угу) зашел на сайт,
а от этого семинара и след простыл...

 

Shit happens!
Александр ногу сломал пару дней назад (((

 

Ты та там бу?

 

Нет