Динамическое обнаружение ошибки переполнения буфера

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

Даже нет никаких идей как это сделать. Прошу подскажите у кого какие идеи есть, заранее спасибо!

0

0

PlayaRC, тему вы создали не в том разделе.
На каком языке вам нужна программа, и вашу тему мы тогда перенесем.

0

С++

Добавлено через 2 часа 41 минуту
Вообще никаких идей? Знаю, что это возможно, так как такие проги существуют

Добавлено через 20 часов 41 минуту
У меня пока что две идеи:
1) (Самая тривиальная) Допустим есть программа, которая принимает на вход данные о человеке и сохраняет их где-то на сервере. Что, если запустить ее в фоновом режиме и спаммить все эти строки до тех пор, пока система не выдаст ошибку переполнения и не закроет программу.
2) (Как по мне, самый правильный способ) Нужно делать дизассемблирование данного .exe и анализировать полученный. Искать в нем строки и смотреть, есть ли там проверки для избежания переполнения

Что скажите?

0

Сообщение от PlayaRC Что, если запустить ее в фоновом режиме и спаммить все эти строки до тех пор, пока система не выдаст ошибку переполнения и не закроет программу.

Это скажет только о том, что в программе есть какая-то критическая ошибка, но никак не укажет даже на факт наличия переполнение буфера, не говоря уже о месте.

Сообщение от PlayaRC Искать в нем строки и смотреть, есть ли там проверки для избежания переполнения

Эта задача крайне нетривиальна даже при наличии исходного кода. Что уж говорить про результаты дизассемблирования. Давайте прикинем на простейшем примере:
Можете сказать, есть тут опасность переполнения?
1. Если RecvSize() возвращает размер данных независимо от Recv(), то за время выполнения потенциально долгого вызова malloc() могла прибежать еще сотня-другая байт и Recv() приняв их все, вызовет переполнение буфера p.
2. Если RecvSize() и Recv() являются свойствами/методами некоторого контекста состояние которого меняется только по требованию программиста, то переполнения быть не может потому что новые данные могут появиться только при вызове некого InquiryNetwork(), который в данном примере между RecvSize() и Recv() никто не вызывал.

Таким образом, без глубинного анализа всего, что касается ф-ций Recv() и RecvSize(), вообще нельзя сделать никаких выводов относительно наличия уязвимости. И это еще примитивнейшая ситуация, без всякого ветвления между вызовами функций, без вызова методов по ссылке и других не поддающихся статическому анализу прелестей. Может вы неправильно поняли задание? Или имелся в виду какой-то один конкретный случай переполнения, который более-менее узнаваем статически?

1

Таким образом, без глубинного анализа всего, что касается ф-ций Recv() и RecvSize(), вообще нельзя сделать никаких выводов относительно наличия уязвимости. И это еще примитивнейшая ситуация, без всякого ветвления между вызовами функций, без вызова методов по ссылке и других не поддающихся статическому анализу прелестей. Может вы неправильно поняли задание? Или имелся в виду какой-то один конкретный случай переполнения, который более-менее узнаваем статически?

Вот теперь я вообще в ступоре! Я имел ввиду что-то типа

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

На первый взгляд я подумал, что это не сложно и взял эту тему.

0

Сообщение от PlayaRC А потом показать, каким образом можно обнаружить уязвимости подобного рода

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

Хотя, я подумал так, а вам ее нужно решить именно статически? Т.е. для готового EXE? Или же можно просто написать свою собственную программу (или создать модуль, подключаемый к любому исходнику), в которую заложен некий механизм автоматического выявления всех происходящих переполнений? Второе вполне реально.

1

Хотя, я подумал так, а вам ее нужно решить именно статически? Т.е. для готового EXE? Или же можно просто написать свою собственную программу (или создать модуль, подключаемый к любому исходнику), в которую заложен некий механизм автоматического выявления всех происходящих переполнений? Второе вполне реально.

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

На счет второго, думаю это мне подходит! Спасибо за совет)
Не подскажите в каком направлении двигаться?

0

Сообщение от PlayaRC Не подскажите в каком направлении двигаться?

Есть метод. Заложитесь на аппаратный механизм защиты памяти. Суть такова:
1. Создаете свои собственные функции управления памятью malloc(), realloc(), free().
2. В них обращаетесь не к менеджеру памяти рантайма, а непосредственно к операционной системе (под Windows это ф-ции VirtualAlloc() и VirtualFree()).
3. Операционная система выделяет память только блоками, размер которых кратен размеру страницы, поэтому malloc() и realloc() должны возвращать адрес не начала выделенного блока а его хвоста с таким расчетом, чтобы от возвращаемого указателя до конца блока было как раз запрашиваемое кол-во байт.
4. В функциях realloc() и free() учитываете п. 3.
5. Подменяете стандартные malloc/realloc/free своими, и после этого любой выход за верхнюю границу динамически выделенного буфера неизбежно ведет к исключению access violation и никакой эксплоит работать не будет (программа упадет или выдаст ошибку, но чужой код не выполнит).

Метод не идеален, но работает. Из недостатков у него очень медленная работа и многократный перерасход памяти. Также он не сработает для статических буферов и выхода за границу вниз, но это на практике встречается несоизмеримо реже. Более подробных рекомендаций не дам, т.к. на C/C++ не пишу.

1

отлично! спасибо большое)

0