Переполнение буфера основанно на содержимом стека, перезаписывая переменную и меняя адрес возврата функции. Атака имеет отношение только к автоматическим данным, которые расположены в стеке. Способ избавиться от проблемы - заменить массивы символов, расположенные в стеке, на динамические переменные, находящиеся в куче. Чтобы сделать это мы заменяем последовательность
#define LG_STRING 128
int fonction (...)
{
char array [LG_STRING];
...
return (result);
}
на:
#define LG_STRING 128
int fonction (...)
{
char *string = NULL;
if ((string = malloc (LG_STRING)) == NULL)
return (-1);
memset(string,'\0',LG_STRING);
[...]
free (string);
return (result);
}
Эти строки увеличивают код и опасность утечки памяти, однако мы должны извлечь преимущество от этих изменений, чтобы изменить подход и избавиться от внушительных ограничений на длину. Надо добавить, что вы не должны ожидать того же результата, используя alloca(). Код получается похожим, однако alloca размещает данные в стеке процесса и это приводит к той же проблеме, что и автоматические переменные. Инициализирование памяти нулем, используя memset(), позволяет избежать некоторых проблем с неинициализированными переменными. Снова, это не решает проблему, эксплоит просто станет сложнее. Те, кто хочет продолжить рассмотрение темы, могут почитать статью о переполнениях кучи от w00w00.
В заключение, скажем, что возможно при некоторых обстоятельствах быстро избавиться от дыр в безопасности добавлением ключевого слова static перед определением буфера. Компилятор разместит эту переменную в сегменте данных далеко от стека процесса. Станет невозможным вызвать оболочку, однако это не решит проблему атаки DoS (Denial of Service - отказ в обслуживании). Естественно, это не будет работать, если процедура вызывается рекурсивно. Это "лечение" должно рассматриваться как смягчающее, используемое только для устранения дыры в безопасности в критическом положении без изменения большого количества кода.