Код:
function_epilogue:
leave ; // закрываем кадр стека небезопасным путем
cmp [esp], offset shielddatabase
; // ^ проверяем границы адреса возврата
jbe .LSHIELDRETRANGE ; // если все ок, то прыгаем на ret
movl eax,1 ; // если мы здесь, то адрес возврата вышел
movl ebx,-1 ; // за допустимые пределы, возможно он был хакнут
int 80h ; // завершаем выполнение программы
.LSHIELDRETRANGE:
ret ; // возвращаемся в материнскую процедуру
Листинг 8 дизассемблерный код, раскрывающий сущность механизма Ret Range Checking
Усилилась и защита локальных переменных. Теперь перед вызовом функции по указателю, Stack-Shield убеждается, что она находится в пределах сегмента кода (см. листинг 9):
Код:
; // в eax находится указатель на функцию
cmp eax, offset shielddatabase
; // проверяем границы указателя
jbe .LSHIELDCALL ; // если указатель в границах, прыгаем на вызов функции
mov eax,1 ; // указатель на функцию выходит за допустимые границы
movl ebx,-1 ; // возможно, он был хакнут
int 80h ; // завершаем выполнение программы
.LSHIELDCALL:
call [eax] ; // вызываем функцию по указателю
Листинг 9 дизассемблерный код, показывающий как Stack-Shield контролирует указатели на функции
Контроль за указателями на функции препятствует непосредственной передаче управления на shell-код, но не мешает хакеру использовать функции стандартной библиотеки libc и функции самой уязвимой программы. Указатели на данные так же остаются незащищенными. Кроме того, при исчерпании массива адреса возвратов (что при глубокой вложенности функций имеет место быть), он автоматически переход в "обычный" режим, в котором проверяет только границы адресов возврата, но не сами адреса. Хорошая новость, нечего сказать!
pro-police
Протектор Pro-Police, зародившийся в недрах японского отделения IBM (http://www.research.ibm.com/trl/projects/security/ssp/), — это, без преувеличения, самый сложный и самый совершенный механизм, реализующий модель безопасного стека (Safe Stack Usage Model), который действительно защищает, а не разводит пропаганду, чтобы выбить очередной грант. Сражение с такой защитой любой самурай почтет за честь.
Pro-police зарывается намного глубже, чем Stack-Guard и работает на уровне RTL. Это не библиотека времени исполнения, это — промежуточный системно-независимый язык, генерируемый компилятором gcc и расшифровываемый как register transfer language. Абстрагирование от оборудования существенно упрощает портирование и pro-police поддерживает практически все современные платформы: Ix86, powerpc, alpha, sparc, mips, vax, m68k, amd64.
Самая главная инновация — переупорядочивание локальных переменных. Pro-police разбивает переменные на две группы: массивы и все остальные. На вершину карда стека попадают обычные, скалярные, переменные. Массивы идут за ними. Переполняющиеся буфера могут воздействовать друг на друга, но до указателей уже не достать, во всяком случае не таким простым путем.
Адрес возврата и указатель кадра защищены сторожевой константой guard, генерируемой произвольном образом. Это все тоже canary word, только в обличии новой терминологии.
Код:
foo()
{
char *p; // локальная переменная-указатель
char buf[128]; // локальный буфер
gets (buf); // функция, которая этот буфер и переполняет
}
Листинг 10 псевдокод уязвимой функции до защиты Pro-Police
Код:
Int32 random_number; // глобальный canary, генерируемый случ. образом
foo ()
{
volatile int32 guard; // локальная копия canary, охраняющая кадр
char buf[128]; // буфер идет перед всеми локальными переменными!
char *p; // локальная переменная-указатель
guard = random_number; // копируем глобальный canary в лок. переменную
gets (buf); // вызываем уязвимую функцию
if (guard != random_number) /* program halts */
}
Листинг 11 псевдокод функции, защищенной Pro-Police (добавленные защитой строки выделены жирным шрифтом)
Код:
Состояние стека на момент вызова функции f из листинга 1 под Pro-Police выглядит так:
[ p ]
[ buf ]
[ guard ]
[ ebp ]
[ retaddr ]
[ arg 1 ]
[ --------- ]
[ --------- ]
[ --------- ]
Листинг 12 cсостояние стека функции foo() на момент завершения выполнения пролога, обратите внимание, что при переполнении буфера buf затирания локальных переменных уже не происходит!
Сравните это с листингом 5. Разница незначительная, но принципиальная! По соображениям производительности, Pro-Police внедряет защиту адреса возврата только функции содержащие буфера, которые потенциально могут быть переполнены. То есть, Pro-Police совмещает в себе защитный механизм с системой аудита кода!
Pro-police предусматривает даже такую неочевидную ситуацию, как подмену указателей, переданных в качестве аргументов и надежно защищает их. В прологе аргументы копируются в промежуточные переменные, расположенные "над" переполняющимся буфером, а не "под" ним (где находятся оригинальные аргументы). В дальнейшем, все обращения к аргументам осуществляются через промежуточные переменные следующим образом:
Код:
foo (int a, void (*fn)())
{
char buf[128]; // локальный буфер
gets (buf); // функция, переполняющая буфер
(*fn)(); // вызов функции, по указателю переданному
// в качестве аргумента и затираемому
// при переполнении
}
Листинг 13 псевдокод уязвимой функции, вызывающей функцию по указателю передаваемому в качестве аргумента, до защиты Pro-Police
Код:
Int32 random_number; // глобальный canary, генерируемый случ. образом
foo (int a, void (*fn)()) // уязвимый аргумент-указатель
{
volatile int32 guard; // локальная копия canary, охраняющая кадр
char buf[128]; // буфер идет перед переменными, но после аргум.
(void *safefn)() = fn; // копируем аргумент во временную переменную
guard = random_number; // копируем глобальный canary в лок. переменную
gets (buf); // вызываем уязвимую функцию
(*safefn)(); // вызываем функцию по скопированному указателю
if (guard != random_number) /* program halts */
}
Листинг 14 псевдокод функции, защищенной Pro-Police (добавленные строки выделены жирным шрифтом)
При всей надежности Pro-Police, отсутствие сторожевых слов между массивами, делает атаку по-прежнему возможной, поскольку затирание нижеследующих массивов порождает целый каскад вторичных переполнений (особенно целочисленных), да и массивы из указателей не такая уж большая редкость. Тем не менее такая проверка (кстати говоря, обещанная в следующих версиях Pro-Police) приведет к существенному падению производительности, что явно пойдет не на пользу ее популярности.
заключение
Так все-таки можно защититься от переполняющихся буферов или нет? Pro-Police отсекает большое количество атак, но… все это атаки на стек, а помимо стека у нас еще есть целочисленное переполнение, спецификаторы и куча, которые Pro-Police даже не пытается охранять, поскольку они находятся вне его "департамента". Это не упрек, а скорее констатация факта.
Личное наблюдение — прочитав несколько популярный статей и установив могучий Pro-Police, большинство знакомых мне программистов упускают из виду, что необходимо установить что-то еще. Безопасное программирование требует целого комплекса совокупных мер, жестоко карая за малейшие ошибки.
Использовать Pro-Police безусловно стоит, равно как и компилировать программы с ключом /GS, однако, необходимо помнить, что эта мера отнюдь не гарантирует защищенности, а всего лишь уменьшает вероятность атаки.
Статья
pass: antichat
Похожие темы
Древовидный вид