Недавно я попытался протестировать учебное приложение для демонстрации переполнения буфера, написанное на C. Я использовал цепочку инструментов Visual Studio 2012 для компиляции и связывания исходников и убедился, что установлены следующие параметры: рандомизация адресного пространства отключена, /GS отключена, что должно отключить защиту стека и защиту от переполнения буфера в «приложении-жертве», которое было уязвимо для переполнения стека. Хотя я все это проделал, в стек добавилось дополнительное место, помимо размера буфера, который я собирался перезаписать своим шелл-кодом. Мне удалось определить адрес возврата, который я хотел заменить начальным адресом буфера, чтобы запустить свой шелл-код из стека. Я получаю следующее сообщение, так как у меня включен флаг /GS, но я этого не делаю:
Stack cookie instrumentation code detected a stack-based buffer overrun.
Вы знаете, в чем может быть проблема? Я использую второе приложение и вызываю свое приложение-жертву с шелл-кодом в качестве параметра из него. Насколько мне известно, это никоим образом не должно мешать тому, как жертва справляется с этим. Я использую вызов WinExec для жертвы из моего приложения для атаки.
Почему я по-прежнему получаю такое же поведение, как и при включенном GS? Я не думаю, что это перезаписывается какой-либо другой опцией, я также отключил /sdl - проверки безопасности. Для компоновщика я добавил следующее: /DYNAMICBASE:NO.
Какие еще параметры мне нужно настроить, чтобы отключить cookie стека и защиту от переполнения буфера? Существуют ли какие-либо другие параметры, помимо этого, для среды, которые мне нужно настроить, чтобы это работало? Кажется, что /GS- на данный момент игнорируется.
Изменить: похожие проблемы, похоже, были рассмотрены здесь: Атака переполнения буфера в Windows приводит к нарушению прав доступа, и я думаю, что это тоже корень моей проблемы. Все упомянутое выше поведение было связано с флагом /NXCOMPAT:NO, который, казалось, вводил поведение размещения адреса возврата дальше в стеке и активации этого механизма защиты стека-куки. При включенном /NXCOMPAT адрес возврата помещается сразу после локальных переменных и базового указателя, если он не пропущен. И я получаю сообщение о нарушении прав доступа. Кому-нибудь удалось обойти это и добиться успешной атаки переполнения буфера на программу, скомпилированную с помощью cl из VS2010 или более поздней версии?
