Это хороший способ проверить переполнение буфера?

Question

У меня установлена ​​старая версия Apache (1.3.x), и я хочу вручную проверить, не подвержена ли она переполнению буфера.Могу ли я просто отправить запрос на получение / публикацию, подобный следующему?

http://127.0.0.1/uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu

Что-то в этом роде, где часть "u" будет похожа на 1000 символов или более?Если сервер уязвим (по крайней мере, в «основной» реализации ...), он должен заморозиться, верно?

И, надеюсь, он не будет полностью падать, и после перезапуска все будет в порядке?Я знаю, что я также могу посмотреть на исходный код.Говоря об этом, интересно, что я только что заметил, что большинство файлов Apache были написаны в 1994 году кем-то по имени МакКул (который утверждает, что не умеет программировать ... в комментариях).Я предполагаю, что переполнения буфера были неслыханными в то время.

Answer 1

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

Anпонимание кода, а также компетентная команда тестировщиков всегда полезно при поиске таких вещей в подобных проектах.

Answer 2

То, что вы, возможно, захотите посмотреть, это нечеткое тестирование и покрытие кода .

По сути, Fuzz-тестирование - это то, что вы предлагаете: отправка мусора в интерфейс и проверка, происходит ли что-нибудь «интересное». К сожалению, «интересный» не очень хорошо определен. Переполнение буфера может вызвать интересные ошибки, такие как «500 Internal Server Error», трассировки стека Java или искаженный вывод мусора. В худшем случае переполнение буфера может привести к остановке всего процесса HTTP-сервера, хотя это может произойти не сразу.

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

Answer 3

На самом деле это не так очевидно, что он потерпит крах.

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