На втором шаге мы вызываем функцию memcpy и копируем shell-код в только что выделенный регион памяти, целевой адрес которого заранее известен. После этой операции shell-код оказывается в области памяти, где разрешено выполнение, и нам остается только засунуть в стек еще один подложный адрес возврата, который будет указывать на shell-код (внимание! функция memcpy в отличие от VirtualAlloc придерживается cdecl соглашения, поэтому после нее мы уже не можем выполнять никакие другие функции, предварительно не удалив аргументы со стека).

Последовательность вызовов, реализующих атаку, выглядит так (напоминаем: это не shell-код, это именно последовательность вызовов API-функций, осуществляемая путем подмены адресов возврата):

Листинг 1. Последовательность вызова функций, реализующих атаку типа commit-n-copy

VirtualAlloc(REMOTE_BASE, SHELLCODE_LENGTH, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

memcpy(REMOTE_BASE, SHELLCODE_BASE, SHELLCODE_LENGTH);

GOTO shell_code;

Маленький нюанс – 64-битные редакции NT передают аргументы APIфункциям через регистры, и потому вызывать VirtualAlloc на них уже не удастся (разумеется, речь идет только о 64-битных приложениях). То есть вызывать-то удастся, а вот передать аргументы – нет, поэтому этот сценарий уже не сработает, однако вызов функций уязвимой программы через подмену адреса возврата будет действовать по-прежнему (то есть запустить tftp.exe мы все-таки сможем, вызывая ее через функцию System, которая по-прежнему принимает аргументы через стек).

Подведем итог: стечение ряда неблагоприятных для DEP обстоятельств делает эту технологию практически полностью бесполезной. Да, она отсекает целый класс атак, основанных на переполнении, однако дает пищу для новых, и в целом ситуация никак не меняется. Забавно, но большинство людей (в том числе и администраторов!) совершенно не понимают, что такое DEP, зачем он нужен, какие цели преследует и в чем заключается взлом. Достаточно почитать дискуссию, развернувшуюся на http://www.mastropaolo.com/?p=13, чтобы убедиться, что оба предложенных сценария обхода DEP не считаются взломом, поскольку x-атрибут присваивается «легальным» способом через вызов VirtualAlloc. На самом деле суть взлома вовсе не в том, чтобы выполнить код в области памяти без x-атрибута (это действительно невозможно), а в том, чтобы использовать уязвимое ПО в своих хакерских целях. В идеале DEP должен представлять собой целый комплекс защитных мер, предотвращающих это, но ничего подобного он не делает, ограничиваясь простой формальной поддержкой NX/XD-атрибутов. Перечислим те обстоятельства, которые ему мешают: