КОГДА В МАЛЕНЬКОЕ ПЫТАЮТСЯ ЗАПИХАТЬ БОЛЬШОЕ...

Vint(vint@townnet.ru)

Спецвыпуск Xakep, номер #032, стр. 032-052-3

Во-вторых, кусок кода должен быть написан так, чтобы не содержать символа 0, который будет понят, как конец строки, иначе этим символом твой кусочек и закончится. Конечно, код попадет при копировании в область параметров, но хакера это, как и испорченный регистр BP, не волнует. Главное, управление будет передано на чужеродный фрагмент.

В-третьих, точно должны быть рассчитаны размеры буфера, чтобы все попало в нужные места и не вызвало обычного core dump. Также надо учесть размеры других переменных, стоящих между буфером и RETADR.

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

МИФ ОБ УНИВЕРСАЛЬНОЙ ЗАЩИТЕ

Недавно на IRC-каналах и в Инете пробегал слушок, что найдена универсальная защита (!) от абсолютно всех нюкеров и эксплоитов, основанных на переполнении буфера. Вот вкратце как это преподносилось: при переполнении стека выполняемый код также находится в стеке (а при нормальной работе ОС такого не бывает), и кому-то, по слухам, нашему соотечественнику Solar Designer'у, пришла в голову мысль, что можно запретить исполнение кода, находящегося в стеке, что должно позволить навсегда решить проблему его переполнения. Этот парень оказался не только говоруном, но и низкоуровневым кодером, и, пошаманив три дня и три ночи с особенностями процессоров Intel 586, реализовал идею в своем проекте OpenWall. Также существуют патч для ядра Linux'а - PAX, заложенный во многие дистрибутивы (например, в BlackCat) и коммерческий продукт под Windows - SecureStack (автор - другой наш соотечественник).

Но при кульном тестинге народ догнал, что это не есть выход! Ведь можно положить в стек данные таким макаром, что после возврата из процедуры ось начнет выполнять любые функции, принадлежащие основной программе, например, memcpy, и ее параметры будут находиться в стеке на положенных местах. В результате функция скопирует данные из стека в другую область памяти, где исполнение кода разрешено, а после возврата из нее управление будет передано в эту область памяти. Все! Универсальная защита от переполнения буфера накрылась :).

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

Сейчас переполнение буфера очень актуально для всех ОС от мелкомягких, даже говорят, что уже найден буфер оверфлов в 2003-х серверных виндах!

Обычно, используя переполнение буфера, ты заставляешь проц выполнить код, который он при нормальной работе выполнять не должен.

Недавно на IRC-каналах и в Инете пробегал слушок, что найдена универсальная защита (!) от абсолютно всех нюкеров и эксплоитов, основанных на переполнении буфера.

Самое примитивное переполнение буфера происходит при работе со строками в текстовых протоколах (HTTP, SMTP, POP, FTP).