Комментарии 24
coverty.com
Скорее всего Вы имели в виду scan.coverity.com/
Спасибо, посмотрю. Но этот судя по описанию тоже из числа низкоуровневых инструментов (почитал у них в факе список обнаруживаемых проблем).
Спасибо, посмотрю. Но этот судя по описанию тоже из числа низкоуровневых инструментов (почитал у них в факе список обнаруживаемых проблем).
я вот это ввиду имел, но все равно вы видимо правы www.coverity.com/products/coverity-prevent.html
>> поиска уязвимостей
А что такое «уязвимости» в вашем понимании?
А что такое «уязвимости» в вашем понимании?
Не будем гнаться за точностью определений, пусть это будет «особенность поведения программы, позволяющая пользователю совершить определённые действия, приводящие к нарушению целостности системы, нарушению её работы, нарушению целостности данных, либо предоставлению пользователю несанкционированного доступа к данным этой или других программ или к средствам управления этой программой или другими программами».
Переполнение буфера, дедлок или дереференсация нулевого указателя являются уязвимостями, если удаётся проследить путь к их возникновению от каких-либо действий пользователя. К сожалению, низкоуровневые инструменты статического анализа часто дают «ложные срабатывания», то есть находят подозрительное место, но его невозможно эксплуатировать. Разумеется, это всё равно плохо, это латентная уязвимость, она сейчас не проявляется, а потом может стать доступной.
Это уязвимости, позволяющие нарушить работу программы. Иногда это нарушение работы имеет более серьёзные последствия в виде повышения уровня доступа, так что пользователь может получить доступ к органам управления программой или операционной системой. Иногда просто можно «уронить» программу.
Есть другой класс уязвимостей, к которым можно отнести SQL-инъекции или XSS, это неразрушающие уязвимости. Они не нарушают работу программы, но используют некоторые особенности обработки данных (чаще всего недостаточной обработки), чтобы получить несанкционированный доступ к некоторым данным (куки, пароли, ...), которые впоследствии также могут быть использованы для получения доступа к органам управления.
Мой вопрос — именно про этот второй тип уязвимостей и про инструменты, предназначенные для их обнаружения. Отличие от первого типа в том, что там можно обнаружить «проблемное» место в программе (где возникает переполнение или используется неинициализированная переменная), а во втором типе такого места нет — «недостаточная обработка данных» как раз характерна тем, что данные где-то нужно было обработать, но этого не произошло.
Переполнение буфера, дедлок или дереференсация нулевого указателя являются уязвимостями, если удаётся проследить путь к их возникновению от каких-либо действий пользователя. К сожалению, низкоуровневые инструменты статического анализа часто дают «ложные срабатывания», то есть находят подозрительное место, но его невозможно эксплуатировать. Разумеется, это всё равно плохо, это латентная уязвимость, она сейчас не проявляется, а потом может стать доступной.
Это уязвимости, позволяющие нарушить работу программы. Иногда это нарушение работы имеет более серьёзные последствия в виде повышения уровня доступа, так что пользователь может получить доступ к органам управления программой или операционной системой. Иногда просто можно «уронить» программу.
Есть другой класс уязвимостей, к которым можно отнести SQL-инъекции или XSS, это неразрушающие уязвимости. Они не нарушают работу программы, но используют некоторые особенности обработки данных (чаще всего недостаточной обработки), чтобы получить несанкционированный доступ к некоторым данным (куки, пароли, ...), которые впоследствии также могут быть использованы для получения доступа к органам управления.
Мой вопрос — именно про этот второй тип уязвимостей и про инструменты, предназначенные для их обнаружения. Отличие от первого типа в том, что там можно обнаружить «проблемное» место в программе (где возникает переполнение или используется неинициализированная переменная), а во втором типе такого места нет — «недостаточная обработка данных» как раз характерна тем, что данные где-то нужно было обработать, но этого не произошло.
По крайней мере в настоящее время различные Static Analysis Tools фиксируют как раз уязвимости первого рода — переполнения, нулл-референс и т.д; в том числе теми методами, что вы определили: анализ потоков данных, исполнение внутри особой управляемой среды с целью фиксации нарушения контрактов пост фактум, так сказать.
Для поиска уязвимостей класса Exploite сейчас применяются другой метод — сопоставление фрагментов кода и с образцами из базы известных уязвимостей для различных паттернов кода и первичный анализ на предмет «подкрутить».
По поводу Pex я подумал вот что, если вдруг вам интересно. Представим программу как идемпотентную (если это не так, то задачу усложняется непринципиально) функцию от входа: Y = F(X). В качестве Y можно предположить данные, удовлетворяющие предикату «выходные данные влекут exploite уязвимости»; они неизвестны, но подчиняются ограничению Y = E(X) — некоторая система ограничений, не выраженная в потоках данных.
Ваша задача в таком случае выглядит так: найти такое допустимое множество X при зафиксированном множестве Y — X = F'(Y). Ясно, что F' — обратная к F. Ясно также, что X = E(Y) — это ограничение на данные, которое придется определять самостоятельно.
Мне кажется, что Pex способен решать такую задачу или ее подзадачу.
Для поиска уязвимостей класса Exploite сейчас применяются другой метод — сопоставление фрагментов кода и с образцами из базы известных уязвимостей для различных паттернов кода и первичный анализ на предмет «подкрутить».
По поводу Pex я подумал вот что, если вдруг вам интересно. Представим программу как идемпотентную (если это не так, то задачу усложняется непринципиально) функцию от входа: Y = F(X). В качестве Y можно предположить данные, удовлетворяющие предикату «выходные данные влекут exploite уязвимости»; они неизвестны, но подчиняются ограничению Y = E(X) — некоторая система ограничений, не выраженная в потоках данных.
Ваша задача в таком случае выглядит так: найти такое допустимое множество X при зафиксированном множестве Y — X = F'(Y). Ясно, что F' — обратная к F. Ясно также, что X = E(Y) — это ограничение на данные, которое придется определять самостоятельно.
Мне кажется, что Pex способен решать такую задачу или ее подзадачу.
Теоретически ясно. Практически — непонятно, как определить предикат E(X). Если я его могу определить, значит я уже должен знать, как проявляется уязвимость. Но я не знаю. А если знаю, тогда Pex уже не нужен. Порочный круг? Или описывать предикат, включающий все возможные проявления? Боюсь, тогда солвер пекса не справится. Мы и так его без труда отправляли в нокаут незначительным увеличением глубины поиска по сравнению с дефолтным.
Кроме того, надо посмотреть, как Pex справится с решением уравнений, где участвуют строковые переменные. С числами-то работать гораздо проще…
А вот про сопоставление фрагментов кода можно поподробнее? Есть такие инструменты? Или всё вручную/на коленке?
Кроме того, надо посмотреть, как Pex справится с решением уравнений, где участвуют строковые переменные. С числами-то работать гораздо проще…
А вот про сопоставление фрагментов кода можно поподробнее? Есть такие инструменты? Или всё вручную/на коленке?
простите, что вмешиваюсь, но это как инструменты статического анализа могут искать уязвимости путем исполнения внутри чего-то, это же уже динамика получается.
Кстати еще добавлю, уж не знаю, как вы собираетесь в программе искать эксплоиты, но занятие это совсем бесполезное. вы наверное запутались в терминологии.
Кстати еще добавлю, уж не знаю, как вы собираетесь в программе искать эксплоиты, но занятие это совсем бесполезное. вы наверное запутались в терминологии.
Да, исполнение в управляемой среде — это уже не статический анализ, верно. Так, например, работает Java Pathfinder, он умеет обнаруживать разные проблемы с синхронизацией потоков — дедлоки, race conditions, искусственно создавая разные конфигурации потоков, управляя скоростью их выполнения. Это не совсем то, что я ищу, но я понял (надеюсь), что имел в виду товарищ sse.
Согласен, спасибо за поправку — тут я поспешно запихнул все в SAT :)
Для с++ подобная штука — valgrind, и, конечно, динамический анализ.
Для с++ подобная штука — valgrind, и, конечно, динамический анализ.
>>в программе искать эксплоиты
Я использовал терминологию, указанную ув. Barancev. Вот что есть в его комментарии:
>>могут быть использованы для получения доступа
Exploite — как раз уязвимость, которая может быть использована злоумышленником.
Или мы о разных вещах говорим, и тут я запутался окончательно :/
Я использовал терминологию, указанную ув. Barancev. Вот что есть в его комментарии:
>>могут быть использованы для получения доступа
Exploite — как раз уязвимость, которая может быть использована злоумышленником.
Или мы о разных вещах говорим, и тут я запутался окончательно :/
Коллега EiZeRR верную поправку внёс. Exploit — это способ использования (эксплуатация) уязвимости, а не сама уязвимость. Соответственно, эксплойт может существовать для уязвимости любого типа.
не будем тут рассуждать кто кого запутал) но эксплоит — это то (скрипт или программа), что использует уязвимость, отсюда и название такое — «эксплуатация уязвимости».
А вообще кажется для динамического анализа любого exe вполне подойдет IDA -к ней еще куча всяких плагинов есть.
А вообще кажется для динамического анализа любого exe вполне подойдет IDA -к ней еще куча всяких плагинов есть.
Klockwork?
www.seclab.tuwien.ac.at/papers/pixy.pdf вот это вот читали? — пункт related works.
Читал. Неутешительно. Но статья трёхлетней давности. Это даёт надежду, что какое-то продвижение случилось и инструменты появились. Не исследовательские статьи, а именно инструменты, пусть хотя бы прототипы или частные реализации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ищу инструменты статического анализа кода для поиска уязвимостей