n  параметры API-функций передаются через стек;

n  адреса API-функций и положение вершины стека легко предсказуемы;

n  всякий процесс может пометить любой регион памяти как «исполняемый»;

n  функция VituallAlloc позволяет выделять/передавать уже переданную память.

В лагере UNIX

Ошибки переполнения не являются «собственностью» Windows. Это общая проблема для всех программ С/С++, родиной которых был и остается UNIX. Уязвимые приложения в изобилии встречаются и там. С ними активно борются путем хитроумных извращений и оригинальных технических решений, о которых мы и собираемся сейчас рассказать.

Начнем с того, что существуют процессорные архитектуры (SPARC, SPARC64, Alpha, HPPA), на которых UNIX имеет неисполняемый стек еще от рождения. Существуют архитектуры, использующие раздельные стеки для хранения адресов возврата и локальных переменных. Подменить адрес возврата на них невозможно, но легко затереть указатель на функцию, при вызове которой управление получит shell-код (правда, передача аргументов представляет собой большую проблему, особенно если они передаются через регистры, тем не менее атаковать такую систему все-таки возможно, пусть и на концептуальном уровне).

На IBM-совместимых машинах LINUX/BSD по умолчанию ведут себя точно так же, как XP без SP2. То есть трактуют r-атрибут как -x-, позволяя исполнять код там, где вздумается. Первой ласточкой, ринувшейся на встречу буре, стал патч от Solar Designer, делающий стек неисполняемым. Хакеров это ничуть не смутило (ведь осталась возможность вызова функций через адрес возврата return-to-libc), но зато помешало многим «честным» программам. В общем, большой популярности это решение не получило.

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

Первое и главное – PaX не требует специальной поддержи со стороны оборудования и не нуждается в битах NX/XD. Вместо этого он группирует сегменты, как показано на рис. 2, и устанавливает лимиты так, чтобы они не пересекались. Несомненный плюс такого решения в том, что для защиты от хакеров нам не нужно приобретать новый процессор – это раз. Shell-код не сможет выделить исполняемый регион в области кучи или стека – это два. Тоже самое, впрочем, относится и к just-in-time компиляторам, поэтому с совместимостью будут проблемы, которые PaX обходит довольно элегантным путем. При аппаратной поддержке со стороны ЦП (биты NX/XD) он может защищать не только весь процесс целиком, но и его отдельную часть. Допустим, мы имеем приложение, нуждающееся в исполняемом стеке, но не присваивающее x-атрибут явно. Под Windows мы будем вынуждены занести его в список программ, на которые механизм DEP не распространяется, со всеми вытекающими отсюда последствиями. А PaX позволяет отключить защиту лишь для части стека! Конечно, это снижает иммунитет системы, но не так радикально, как полное отключение DEP. К тому же рандомизация адресов не позволяет shell-коду добраться до этой исполняемой области и использовать ее в своих целях.