Как сообщить о переполнении буфера стека в Windows?

Функция CRT, которая обрабатывает обнаружение переполнения буфера стека, __report_gsfailure(), предполагает, что повреждение кадра стека было вызвано атакой вредоносного ПО. Такое вредоносное ПО традиционно связывалось с фильтрами исключений fs:[0] SEH (хранящимися во фрейме стека), чтобы получить обработчик исключений для запуска полезной нагрузки вредоносного ПО. Один из способов заставить данные превратиться в исполняемый код.

Так что функция CRT не может предположить, что создание исключения безопасно. И больше не входит в CRT, включенный в VS2013, восходит к ~ VS2005. Он будет отказоустойчивым, если ОС его поддерживает, а если нет, гарантирует, что зарегистрированный обработчик исключений VEH/SEH также не сможет увидеть исключение. Kaboom, вылет на рабочий стол без диагностики, если у вас не подключен отладчик.

Параметр /SAFESEH предотвращает подобные атаки вредоносных программ, поэтому они не так серьезны, как раньше. Если вы все еще находитесь на этапе, когда ваш код страдает от ошибок, приводящих к повреждению стека, а ваше приложение недостаточно популярно, чтобы стать мишенью вредоносного ПО, вы можете подумать о замене функции CRT.

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

Вставьте этот код где-нибудь рядом с вашей функцией main():

__declspec(noreturn) extern "C"
void __cdecl __report_gsfailure() {
    RaiseException(STATUS_STACK_BUFFER_OVERRUN, EXCEPTION_NONCONTINUABLE, 0, nullptr);
}

И планирую удалить его снова в ближайшее время.

Нет решения заданного вопроса.

Выход за пределы массива приводит к неопределенному поведению в стандартном C++, поэтому никакой конкретный результат не гарантируется. Неспособность дать надежный результат не является проблемой для компилятора — это допустимое поведение.

Я не знаю ни одной реализации, которая гарантировала бы какое-либо конкретное поведение в ответ на переполнение - VS, конечно, этого не делает. Что неудивительно, поскольку от компиляторов этого не требуется (в этом, по сути, смысл неопределенного поведения). Причина этого заключается в том, что часто бывает трудно надежно или постоянно обнаруживать такие случаи.

Это означает, что единственный непротиворечивый способ обнаружить переполнение массива — это проверить допустимость индексов массива ДО их использования для доступа к элементу массива и предпринять соответствующие действия (например, создать исключение, которое можно перехватить, вместо того, чтобы выполнять неверную операцию). Недостатком является то, что он не предоставляет простого и надежного способа обнаружения ошибок в произвольном коде, за исключением изменения всего кода для выполнения необходимых проверок.

Я хотел бы прокомментировать принятый ответ, но я только что присоединился и еще не имею достаточной репутации, чтобы сделать это.

Я попробовал решение с Visual Studio 2017, и мне пришлось внести пару изменений, чтобы решение скомпилировалось.

Сначала мне пришлось изменить подпись __report_gsfailure, чтобы она соответствовала одному из заголовочных файлов Microsoft, чтобы исправить ошибку компиляции.

__declspec(noreturn) extern "C" void __cdecl __report_gsfailure(_In_ uintptr_t _StackCookie)
{
    RaiseException(STATUS_STACK_BUFFER_OVERRUN, EXCEPTION_NONCONTINUABLE, 0, nullptr);
}

Затем я столкнулся с ошибкой LNK2005, которую мне удалось исправить, добавив /FORCE:MULTIPLE в Linker->Command Line для свойств моего проекта.