книги хакеры / журнал хакер / специальные выпуски / Специальный выпуск 71_Optimized

введение. Проблемы утечки ресурсов и пере-

полнения буферов главным образом относятся к Си

(и в меньшей степени к его преемнику — Си++). Это

не покажется удивительным, если вспомнить, что

Си — самый низкоуровневый из всех высокоуров-

Что же касается Си++, то это гибрид, вобравший

что еще можно ожидать от Бейсика, пускай и прод-

невых языков, всего лишь на одну ступень отстоя-

в себя множество концепций и парадигм програм-

вигаемого под видом Си?). В конечном счете, ком-

щий от ассемблера. Си делает только то, о чем его

мирования, позаимствованных из таких языков

пания была вынуждена похоронить миллионы

просят, вынуждая программиста самостоятельно

как, например, ADA или Smalltalk, но все равно ос-

строк, и начать разработку заново. Если не ошиба-

выделять и освобождать память, контролировать

тавшийся «ручным». В нем нет ни сборщика мусо-

юсь, текущая версия Windows Vista базируется на

границы буферов и заботиться о массе других ве-

ра, ни динамических стековых массивов, ни авто-

коде Server 2003, написанном на смеси Си с Си++,

щей, которые на Java, С# и многих других языках

матического контроля границ, ни многих других ве-

а это значит, что отказ от Си/Си++ (по крайней ме-

автоматически выполняются компилятором (инте-

щей, которые по-прежнему приходится делать ру-

ре, в крупных проектах) невозможен, и вместо то-

рпретатором). Однако ни один из них не завоевал

ками. А нет их там потому, что вся эта «автомати-

го, чтобы жаловаться на судьбу, лучше придумать

такой популярности, как Си, и навряд ли завоюет ее

зация» заметно снижает производительность и

пару-тройку новых методов б орьбы с утечками и

в дальнейшем. Почему? На Си написано огромное

превращает Си++ в пародию на Visual Basic, яр-

переполняющимися буферами, о чем мы сейчас

количество программ, которые необходимо разви-

чайшим примером которой является C#. Ходят ус-

и поговорим.

вать и поддерживать, Си обеспечивает максималь-

тойчивые слухи, что значительная часть Longhorn'а

переполняющиеся буферы. Ошибок пере-

ную производительность и переносимость, в то вре-

была написана на C#, но, несмотря на все усилия

полнения не избежала практически ни одна чуть

мя как его конкуренты предлагают либо производи-

разработчиков, достичь приемлемой производи-

более сложная, чем «hello, world!», программа,

тельность, либо переносимость.

тельности и стабильности им так и не удалось (а

а все потому, что ошибки переполнения в Си носят

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

Мы видим, что _msize ведет себя очень странно и

Размер буфера может быть как фиксированным,

ляет никаких механизмов для их преодоления.

когда не может определить размер блока, возвра-

так и динамическим. Хорошей стратег выделяет

Контроль границ буфера приходится осуще-

щает какой-то мусор, никак не сигнализируя об

под первый элемент списка 64 байта, под второй

ствлять вручную. К тому же, если говорить по су-

ошибке. Поэтому выполнять контроль должна вы-

128 байт и так далее, вплоть до 1000h, что позволя-

ществу, в Си вообще нет никаких буферов. Полу-

зывающая функция, передавая вызываемой раз-

ет обрабатывать как длинные, так и короткие сро-

чив указатель на «буфер», функция не может оп-

мер буфера как аргумент. Отсюда и появились

ки с минимальным оверхидом.

ределить его длину. Оператор sizeof возвращает

char *fgets(char *string, int n, FILE *stream); char

Списки на 100% защищены от ошибок пере-

размер указателя (как правило, равный DWORD),

*strncpy(char *strDest, const char *strSource, size_t

полнения (исключение составляют попытки обра-

но отнюдь не размер блока, на который он указы-

count) и другие подобные функции. Теоретически,

ботать строку свыше 2 Гб, вызывающую исчерпа-

вает. Небольшую лазейку оставляет нестандарт-

они на 100% застрахованы от переполнения, но

ние свободной памяти, но, во-первых, исчерпа-

ная функция _msize, сообщающая размер дина-

вот практически… значение n приходится рассчи-

ние — это все-таки не переполнение, и заслать

мического блока, но она требует указателя на его

тывать вручную, а, значит, существует риск оши-

shell-код злоумышленник не сможет, а во-вторых,

начало, отказываясь работать с серединой.

биться! К тому же, если длина строки превышает

это явная ошибка, которую легко обработать, ус-

Простейшая тестовая программа все это

n, в буфер копируется лишь «огрызок», что само

тановив предельный лимит на максимально ра-

наглядно подтверждает:

по себе является нехилым источником проблем и

зумную длину строки).

вторичных ошибок. Приходится навешивать спе-

Хуже другое. Реализовав свою библиотеку

циальный обработчик, выделяющий дополнитель-

для работы со «списочными строками», мы будем

программа, демонстрирующая невозможность

определения размера блока по указателю

ную память и считывающий оставшийся «хвост»,

вынуждены переписать все остальные библиотеки,

что значительно усложняет реализацию, делает

создавая обертки для каждой строковой функции,

// функция, принимающая указатель

код более громоздким и менее наглядным. Обыч-

включая fopen, CreateProcess и т. д., поскольку все

// и пытающаяся определить размер

соответствующего ему блока

но стараются выбрать n так, чтобы его значение

они ожидают увидеть непрерывный массив байт,

превышало размер наибольшей строки, выделяя

а вовсе не список! Это чрезвычайно утомительная

foo(char *p){printf("sizeof says =

%Xh\n_msize says =

память с запасом и не обращая внимания на то,

работа, но зато когда она будет закончена, о пере-

что большинство строк использует лишь малую

полнениях можно забыть раз и навсегда. Правда,

%Xh\n",sizeof(p),_msize(p));}

часть буфера…

производительность (за счет постоянного преобра-

Нет! Память лучше всего выделять динами-

зования типов) падает весьма значительно…

main()

чески, по мере возникновения в ней потребности!

А вот более быстрое, но менее надежное ре-

{

В идеале, строка должна представлять собой список

шение. Отказываемся от стековых буферов, пере-

char buf[0x666]; char *p =

malloc(0x999);

(желательно двухсвязный), что не только ускорит

ходя на динамическую память. Выделяем каждо-

операции удаления и вставки подстрок, но и ликви-

му блоку на одну страницу больше и присваиваем

дирует проблему переполнения. О контроле границ

последней странице атрибут PAGE_NOACCESS,

// передаем указатель на начало блока

заботиться уже необязательно, поскольку память

чтобы каждое обращение к ней вызывало исклю-

foo(buf);foo(p);

под новые символы выделяется автоматически.

чение, отлавливаемое нашим обработчиком, ко-

В простейшем случае каждый элемент спис-

торый в зависимости от ситуации либо увеличи-

// передаем указатель на середину блока

ка выглядит приблизительно так:

вал размер буфера, либо завершал работу прог-

foo(&buf[6]);foo(p+9);

раммы с сообщением об ошибке. На коротких

}

строках оверхид весьма значителен, но на длин-

struct slist

После запуска мы получим следующие весьма не-

ных он минимален. Но к сожалению, такая защита

{

утешительные данные:

страхует лишь от последовательного переполне-

unsigned char c;

ния, но бессильна предотвратить индексное (под-

struct slist *prev;

результат работы программы, определяющий раз-

робнее о видах переполнения можно прочитать

struct slist *next;

мер блока по указателю

в моей книжке «Shellcoders's programming uncov-

struct slist *first;

ered», которую можно найти в Осле), к тому же,

// указатель на начало стекового буфера

struct slist *last;

переход на динамические массивы порождает

sizeof says = 4h, _msize says =

};

проблему утечек памяти и получается так, что од-

12E8CEh // sizeof и _msize провалились

Это просто реализуется, но имеет дикий оверхид,

но лечим, а другое калечим.

требующий для хранения каждого символа 17

Тем не менее, лишний раз подстраховаться

// указатель на начало динамического

буфера

байт, поэтому на практике приходится использо-

никогда не помешает! Чтобы защититься от пере-

вать комбинированный способ, сочетающий в себе

полнения кучи (которое в последнее время приоб-

sizeof says = 4h, _msize says =

строковые буферы со списками:

ретает все большую популярность) после вызова

9A0h // sizeof провалилась, _msize —

почти ОК

любой функции, работающей с динамической па-

мятью, необходимо защищать служебные данные

#define STR_SIZE256

кучи атрибутом PAGE_NOACCESS, а перед вызо-

// указатель на середину стекового буфера

struct slist

вом функции — снимать их. Для этого нам, опять-

sizeof says = 4h, _msize says =

{

таки, потребуется написать обертки вокруг всех

FFFFFFFFh

// sizeof è _msize

unsigned int len;

функций менеджера памяти, что требует времени.

провалились

unsigned char buf[STR_SIZE];

К тому же, в реализации кучи от Microsoft Visual

struct slist *prev;

C++ служебные данные лежат по смещению -10h

// указатель на середину динамического

struct slist *next;

от начала выделенного блока, а защищать мы мо-

буфера

struct slist *first;

жем только всю страницу целиком. Поэтому, во-

sizeof says = 4h, _msize says =

struct slist *last;

первых, необходимо увеличить размер каждого

D200h // sizeof и _msize провалились

};

блока до 512 Кбайт, чтобы начальный адрес сов-

…

На самом деле, выделять динамические массивы

падал с началом страницы, а во-вторых, использо-

все-таки возможно, но только в том случае если

p2 = malloc(XXL);

вать блок только со второй страницы. В результа-

компилятор, во-первых, адресует локальные пере-

…

те, при работе с мелкими блоками мы получаем

менные через EBP, а во-вторых, в эпилоге исполь-

} while(0);

чудовищный оверхид, но зато компенсируемый

зует конструкцию MOV ESP, EBP вместо ADD ESP,

free(p1); free(p2);

надежной защитой от переполнения. Так что дан-

n. К таким компиляторам, в частности, относится

if (ff) fclose(ff);

ный метод, при всех его недостатках, все-таки

Microsoft Visual C++, автоматически переходящий

return error;

имеет право на жизнь.

на адресацию локальных переменных через ре-

}

утечки ресурсов возникают всякий раз, когда

гистр EBP, если в теле функции присутствует хотя

функция выделяет блок памяти, открывает файл, но

Что изменилось? Абсолютно все! Теперь для внеп-

бы одна ассемблерная вставка.

при выходе забывает его освободить/закрыть. Ча-

ланового выхода из программы (который осущес-

Фрагмент одной из таких функций приведен

ще всего это происходит при преждевременном вы-

твляется по break), нам уже не нужно помнить, что

ниже (компилировано Microsoft Visual C++ с мак-

ходе из функции. Рассмотрим следующий пример:

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

симальной оптимизацией (ключ /Ox):

цикла while (который на самом деле никакой не

цикл, а просто имитация критикуемого оператора

foo()

text:00000010

push

ebp

goto), мы освобождаем (или, точнее, пытаемся ос-

{

text:00000011

mov

ebp, esp

вободить) все ресурсы, которые потенциально

FILE *ff

text:00000013

push

esi

могли быть выделены. Структура программы зна-

char *p1, *p2;

…