-
-
[旧帖]
[原创]__report_gsfailure中UEF的特殊行为
0.00雪花
-
2011-5-9 14:11
3131
-
[旧帖] [原创]__report_gsfailure中UEF的特殊行为
0.00雪花
原本以为对UEF的逻辑已经大概了解了（
理解UnhandledExceptionFilter），最近调试__report_gsfailure的时候却碰到了新问题。从VS2005以来，编译器添加了对栈的保护检查以防止buffer overrun的危害。一旦发现栈的内容出现错误，会调用__report_gsfailure，代码如下：
1. DebuggerWasPresent = IsDebuggerPresent();
2. _CRT_DEBUGGER_HOOK(_CRT_DEBUGGER_GSFAILURE);
3.
4. SetUnhandledExceptionFilter(NULL);
5. UnhandledExceptionFilter((EXCEPTION_POINTERS *)&GS_ExceptionPointers);
6. if (!DebuggerWasPresent)
7. {
8. _CRT_DEBUGGER_HOOK(_CRT_DEBUGGER_GSFAILURE);
9. }
10.TerminateProcess(GetCurrentProcess(), STATUS_STACK_BUFFER_OVERRUN);
使用一小段简单的代码即可测试之，
char overBuf[8];
DWORD dwForBuf;
char anotherBuf[8];
DWORD dwForAnotherBuf;
dwForBuf = 0x12341234;
// break compiler fense
strcpy( overBuf, "12345678""\xcc\xcc\xcc\xcc""1234" );
dwForAnotherBuf = 0xabcdabcd;
strcpy( anotherBuf, "0123" );
1. 使用VS调试的时候，执行到最后会在第2行_CRT_DEBUGGER_HOOK处断下来，不知道原因，怀疑是VS做了特别的处理，因为使用windbg调试的时候，就象是执行了一个普通的函数，没有任何问题。
2. 使用windbg的时候，是断在了kernel32!UnhandledExceptionFilter里，也就执行第5行的时候，有个int 3的断点指令。记得UEF的处理逻辑是在调试器里运行的时候直接返回EXCEPTION_CONTINUE_SEARCH， 为什么会产生了断点？
3. 如果在调试器外执行，结果应该如何？
第一个问题的答案在这：
__report_gsfailure中UEF的特殊行为(1)
第二个问题的答案在这：
__report_gsfailure中UEF的特殊行为(2)
第三个问题的答案在这：
__report_gsfailure中UEF的特殊行为(3)
[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界
