我尝试使用example中的boost::asio::spawn
功能,但它在发布时出现以下错误:
libboost_context-vc120-mt-s-1_55.lib(jump_i386_ms_pe_masm.obj):错误 LNK2026:SAFESEH图像模块不安全
很明显,我应该在项目设置中设置/SAFESEH:NO
选项,但我无法理解这实际上会做什么。这会如何影响程序中的异常处理行为(包括C ++异常和SEH)?
顺便说一句,我使用的是MSVC-12.0。
答案 0 :(得分:13)
简短回答:停用SafeSEH会降低程序安全性。
详细信息:SafeSEH是编译器保护。
在Windows环境中,SEH(结构化Exception Handler)记录的布局如下
Stack data (pointed by TEB - thread environment block)
|
| I) Pointer to next SEH record II
| EH pointer
|
| II) Pointer to next SEH record III
| EH pointer
|
| 0xFFFFFF
| default EH (MSVCRT)
通常基于SEH的攻击依赖于覆盖上述记录之一并让应用程序抛出异常:这将绕过代码的控制流程(我强>> 考虑到DEP / ASLR保护系统在这里,我假设一个已知的+ X位置)。更确切地说,他们经常"模拟EH回归"他们取下了下一个"邪恶的"指向跳转到shellcode的指针。
SafeSEH的工作原理是指示操作系统在跳转到它们之前首先检查处理程序指针的有效性(针对已知有效EH的表)。这个过程有一些限制,在特殊情况下,应用程序可能仍然容易受到攻击,但基于SEH的攻击不太可能发生(或者更难以制作)。
当链接到非安全的SEH编译模块时,链接器无法生成一个"受信任的表" EH位置(它根本无法分辨哪些是否是有效的EH)从而导致您获得的错误。
对Windows操作系统工程的一些后勤限制,兼容性原因以及控制地址超出加载模块范围(和可执行映像)的问题导致选择默认禁用此选项并让用户选择是否启用它。
如果您的应用程序迫切需要安全性并且您认为上述方案存在潜在威胁,则应启用它并重新编译模块以便使用它。
答案 1 :(得分:0)
/ SAFESEH生成一个“安全异常处理程序表”:
>dumpbin safeseh_yes.dll /loadconfig | find "xcept"
3001F4D0 Safe Exception Handler Table
1 Safe Exception Handler Count
Safe Exception Handler Table
30018FE0 __except_handler4
/ SAFESEH:NO不生成表:
>dumpbin safeseh_no.dll /loadconfig | find "xcept"
00000000 Safe Exception Handler Table
0 Safe Exception Handler Count
如果存在该表,则操作系统会在调用该表之前使用它来验证SEH处理程序是否有效。