Как ищут уязвимости класов bufer overflow и format string

Изучение исходников?
Дизассемблирование?
Ещё как-то?
Возможный алгоритм действий при поиске этих уязвимостей?
Как это бывает на самом деле?
Может кто-нибудь поделится собственной реальной историей нахождения уязвимости?

 

Как первое так и второе.

А вообще вроде есть проги для частичной автоматизации этого процесса.

Идея такая берется API функция которой передается группа параметров и в цикле пытается засунуть туда длинные переменные.

Отслеживая вылетит ли прога.

 

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

 

vg
Случайным образом их ищут. Разработчик невнимательно читает спецификации или неаккуратно программит , и БАЦ - открытие. Если бы был способ - разботчики им бы пользовались.

 

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

 

valterg

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

vg
Почитай книгу "Exploiting Software" Хоглунда и Мак Гроу, найдешь очень много интересного, и простой язык.

 

valterg

Да. Ищут именно так. Ищут, ищут, ищут... А находят - все равно случайным образом.

 

Osen
drmad
Я понимаю, что есть инструменты. Но разработчики все-таки старются, чтобы явных дырок не было.
С помощью инструментов вы опупеете все параметры проверять. И не надо мне говорить, что не все - буферов тоже много, я про них только и говорю. Поэтому в реале находят все-таки случайно. Если бы был простой инструмент, то разрабочики им бы все и проверили. Все-таки всех избаловала автоматизация : для любой задачки -сотня инструментов, все вроде решено, а проблемы все сложнее
и ошибку хрен найдешь.

 

На самом деле не такая уж и глупость. Именно случайно и находят ...

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

 

asmlamo
+1 Сам в свое время писал через NFS в Юникс. Просто NFS был ДОС-овый и естественно юзер =0,0
Из Юникса надо было быть root-ом, а вот из ДОС-а - кем угодно.
Кто здесь виноват : разработчик NFS для ДОС или это уязвимость NFS Юникса?

 

asmlamo, valterg
Вы видимо бооольшие спецы по поиску уязвимостей. Случайного ничего не бывает.

 

Osen

Тогда оспорьте мой пример про NFS. Мне надо было прочесть файлы с удаленного сервера.
Ничего писать я не собирался. Юникс естественно не подключался(был он у меня),
наверно все-таки уязвимости были закрыты. И была "вредная привычка" жать F8 - наверное
от Турбо-Паскаля и знание про Deco(demos commander)... Если это не случайность...

 

valterg

Есть например valgrind, он не столько уязвимости ищет, сколько просто ошибки, но сколько я встречал софта, который откровенно содержит ошибки отлавливаемые valgrind'ом -- не сосчитать.
valterg

Эта уязвимость называется "админ".

 

valgrind она идет только под линукс:???

 

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

 

да

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

 

А под винду есть что то подобное ??? =)

 

Osen
r90

Сейчас, я согласен. Тогда, ну никак нельзя было предусмотреть. Именно про это и речь. Вы защищаетесь от супер-хакера и совершенно беззащитны от ламера, который тупо проверяет все инструкции от А до Я. Вы тоже их можете проверить, но вам не хватит времени сдать проект.
Ну кому могло прийти в голову выводить через MessageBox строчку типа \\?\C:\....
Но оказалось, что все ОС от ХП до Висты - выдают BSOD... Микрософт официально признало баг, найденный случайно(!) обычным программистом - ну поленился он другую функцию использовать для списка открытых файлов.

 

valterg
Между прочим - тупо перебирать все возможные варианты входных данных - один из методов поиска уязвимостей известный всем. Да, соглашусь, что бывает и случайно, но это бывает ОЧЕНЬ редко, до такой степени, что можно это опустить.

 

calidus
Можно еще глянуть splint, я его под win32 запускал, проблема в том, что он не переваривает VC-хидеры и "анализировать" в нем можно тока ANSI C исходники.