SAFESEH：NO选项实际上是做什么的 [英] What SAFESEH:NO option actually do

问题描述

我正在尝试使用 boost :: asio :: spawn 函数，如示例，但它在发行版中给了我以下错误：

I'm trying to use boost::asio::spawn function like in the example, but it gives me the following error in Release:

libboost_context-vc120-mt-s-1_55.lib（jump_i386_ms_pe_masm.obj）：错误
LNK2026：模块不安全的SAFESEH映像

libboost_context-vc120-mt-s-1_55.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image

很明显，我应该在项目设置中设置 / SAFESEH：NO 选项，但是我不能了解这实际上会做什么。这如何影响程序中异常处理的行为（C ++异常和SEH）？

It is clear that I should set /SAFESEH:NO option in the project's settings but I can't understand what this will actually do. How this affect the behavior of exception handling in the program (both C++ exceptions and SEH)?

btw我正在使用MSVC-12.0。

btw I'm using MSVC-12.0.

推荐答案

简短答案：禁用SafeSEH会降低程序安全性。

详细信息： SafeSEH 是编译器保护。

Details: SafeSEH is a compiler protection.

在Windows环境SEH上（构造为异常处理程序）记录的布局如下

On a Windows environment SEH (Structured Exception Handler) records are laid out as follows

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。

Usually SEH-based attacks rely on overwriting one of the above records and having the application throw an exception: this will detour the control flow to your code (I'm not taking into account DEP/ASLR protection systems here so I'm assuming a known +X location). More precisely they often "simulate a EH return" and they fetch the next "evil-crafted" pointer to jump to the shellcode.

SafeSEH通过指示操作系统执行以下操作：首先，请检查处理程序指针的有效性（针对已知有效EH的表），然后再跳转至它们。此过程有一些限制，在特殊情况下，应用程序可能仍然容易受到攻击，但基于SEH的攻击不太可能发生（或者很难制造）。

SafeSEH works by instructing the operating system to first check the handler pointers for validity (against a table of known valid EHs) before jumping to them. There are a few restrictions to this process and under special circumstances an application might still be vulnerable but a SEH-based attack is less likely to take place (or significantly harder to craft).

当链接到非safeSEH编译的模块时，链接器将无法生成EH位置的可信表（它根本无法分辨这些位置和有效的EH），因此会出现错误。

When linking against a non-safeSEH compiled module the linker won't be able to generate a "trusted table" of EH locations (it simply cannot tell where and if those are valid EHs) thus the error you're getting.

由于Windows操作系统工程上的一些物流限制，兼容性原因以及控制地址落入已加载模块（和可执行映像）范围之外的问题，导致了选择

Some logistic restrictions on the Windows OS engineering, compatibility reasons and the problems bound to controlling addresses falling out of the range of loaded modules (and executable image) led to the choice of disabling this option by default and leaving the user the choice whether to enable it or not.

如果您的应用迫切需要安全性，并且您认为上述情况是潜在的威胁，则默认为禁用此选项，然后让用户选择是否启用它。您应该启用它并重新编译模块才能使用它。

If your application desperately needs security and you repute the above scenario a potential threat, you should enable it and recompile your modules in order to use it.

这篇关于SAFESEH：NO选项实际上是做什么的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！