SEH(结构化异常处理)PPT课件
- 格式:ppt
- 大小:132.00 KB
- 文档页数:28
二进制漏洞挖掘系列课程-(2)利用SEH绕过GS安全机制其实Windows在原始的程序栈前面添加了一个异常处理结构,该结构由一系列的异常处理链表组成,这条链表的起始点总是放在TIB(Thread Information Block)的第一个成员中,在x86计算机中存储在FS:[0]寄存器中。
链表的最后总是默认处理程序,这个默认处理程序的指针总是0xFFFFFFFFGS保护机制:Windows在VS7.0(Visual Studio2003)及以后版本的VisualStudio中默认启动了一个安全编译选项——GS(针对缓冲区溢出时覆盖函数返回地址这一特征)GS保护机制是在函数即将调用的时候向栈桢压入一个DWORD的随机值,同时也向.data段中存放一个Security Cookies,1.被压入栈中的随机值位于EBP之前.在.data段中的数据实现栈Cookies的校验2.在函数返回之前,系统将会执行一个额外的安全验证操作,被称作SecurityCheck3.Security当校验发现栈Cookies和.data的副本不吻合则表明发生溢出4.当检测到栈中发生溢出时,系统接管异常,函数不会被正常返回,ret指令也不会被执行5.当栈中发生溢出时,Security Cookie将被首先淹没,之后才是EBP和返回地址GS保护机制的实现细节是1系统以.data段的第一个DWORD作为Cookie的种子2每次程序运行时的Cookie的种子都不一样,随机性很强3栈桢初始化完毕后用EBP异或种子,作为当前函数的Cookie,以此区别不同函数,增强Cookie的随机性4在函数返回前,用EBP异或还原出Cookie种子绕过GS安全保护的方案1)通过覆盖SEH链表来阻止系统接管异常处理.2)通过改写C++虚表指针来控制程序流程3)用一些未开启GS安全保护的函数进行溢出(可能是关键字保护)||小于四字节的Buf 今天这个课程我们讲通过覆盖SEH链表来进行exploit还是上节课的例子,我们开始调试在反汇编窗口查看ShowFileInfo这次为了演示seh我把print函数放在了ReadFile下面我们这次看到了在ShowFileInfo中Printf函数下面有一个Security_Check_Cookie这就是我们的GS缓冲区检测机制的这个函数,工程项目是realse版本的,在项目属性只开启GS。
Win32结构化异常处理(SEH)探秘(上)在 Win32 操作系统提供的所有功能中,使用最广泛但最缺乏文档描述的也许就是结构化异常处理了(SEH),当你考虑Win32 结构化异常处理时,你也许会想到诸如 _try,_finally 以及 _except 这些术语。
你能在任何有关 Win32 的书中发现对 SEH 很好的描述(即使是 remedial)。
即便是 Win32 SDK 也具备有相当完整的使用 _try,_finally 和 _except 进行结构化异常处理的概述。
有了这些文档,那为何还说 SEH 缺乏文档呢?其实,Win32 结构化异常处理是操作系统提供的一个服务。
你能找到的关于 SEH 的所有文档都是描述特定编译器的运行时库,这个运行库对操作系统实现进行包装。
_try,_finally 和 _except 这些关键字没有任何神奇的地方。
微软的操作系统及其编译器系列定义这些关键字和用法。
其他的编译器提供商则只是沿用这些语义。
虽然借助编译器层的 SEH 可以挽回一些原始操作系统级 SEH 处理不良口碑,但在大众眼里对原始操作系统 SEH 细节的处理感觉依旧。
我收到人们大量的e-mail,都是想要实现编译器级的 SEH 处理,又无法找到操作系统功能提供的相关文档。
通常我都是建议参考 Visual C++ 或者 Borland C++ 运行库源代码。
唉,出于一些未知的原因,编译器级的 SEH 似乎是一个大的秘密,微软和 Borland 都不提供其对 SEH 支持的核心层源代码。
在本文中,我将一层一层对 SEH 进行解剖,以便展现其最基本的概念。
我打算通过代码产生和运行时库支持将操作系统提供的功能和编译器提供的功能分开。
当我深入代码考察关键的操作系统例程时,我将使用 Intel 平台上的 Windows NT4.0 作为基础。
但我将要描述的大多数内容同样适用于其它处理器上运行的应用。
我打算避免涉及到真正的 C++ 异常处理,它们使用 catch(),而不是 _except。