通过结构化异常处理绕过CFG

我们原来发布了一个基于泄漏堆栈地址并覆盖结构化异常处理程序的技术，从而将一个使用Use-After-Free(UAF)类型的漏洞转换为结构化异常处理的程序。

在本文中为了方便CFG的绕过，我们再次选择使用Internet Explorer 11的Microsoft Windows WPAD权限提升漏洞 (MS16-063)，2016年6月，Theori曾发表了一篇关于MS16-063中修补了的IE漏洞分析 ，文中发布的漏洞攻击仅是针对Windows7上的IE 11版本，此外由于Windows 10采用了CFG机制所以无法对Windows 10设备进行攻击。

但我们之前已经发布过两篇文章讨论过如何绕过Windows 10环境下的CFG,第一篇请点击这里，另一篇请点击这里。

堆栈的泄漏

在以前的文章中我们已经获得了Clean_Poc.html的POC文件，并利用MS16-063漏洞获得了序列化执行权限（ read/write primitive），但没有再往下进一步分析。在Leaking_Stack.html的 POC文件中，当前线程的堆栈限制被泄露，这是使用kernelbase.dll中的GetCurrentThreadStackLimits API完成的，具体的执行方法是，GetCurrentThreadStackLimits API通过TypedArray对象调用虚拟函数表（vtable），具体的调用过程如下：

我们可以看出，调用发生在虚拟函数表中的偏移0x188处，因为虚拟函数表可以直接从Javascript代码调用并具有两个参数，这对调用非常重要，因为必须确保函数必须具有同等数量的参数，否则堆栈将在返回时引起调用异常。

我们在本文中使用的API是GetCurrentThreadStackLimits，它很容易从MSDN中获取可用的JavaScript调用，如下所示。

GetCurrentThreadStackLimits需要两个参数，并返回堆栈基地址和堆栈的最大保留地址，我们可以通过两个步骤找到GetCurrentThreadStackLimits的地址。

首先将指针泄漏到kernelbase.dll中，然后在DLL中对该函数进行定位。第一部分是通过首先定位jscript9中的Segment :: Initialize函数来完成的，因为它使用了kernel32！VirtualAllocStub及kernelbase！VirtualAlloc。我们是通过在虚拟函数表的地址中扫描jscript9并计算哈希值来找到这个方法的，这是使用序列化执行权限完成的，算法如下图所示。

通过添加5个双字，我们可以每次向前遍历一个字节，直到找到正确的哈希值。非常简单的哈希函数实际上是无冲突的。在Segment :: Initialize函数中的偏移量0x37处，kernel32！VirtualAlloc的解引用调用发生，如下所示。

通过这个指针可以获取以下内容：

然后在kernelbase!VirtualAlloc的偏移0x6处，内核发生跳转。

现在我们就获得了一个指向kernelbase.dll的指针了，然后我们使用与Segment :: Initialize相同的方法找到GetCurrentThreadStackLimits的地址，如下所示。

我们现在可以创建一个假的虚拟函数表，就像Theori在MS16-063中所做的那样，并用这个函数指针修改偏移量0x188处的的虚拟函数表条目，不过要记住增加TypedArray的size参数，然后代码变成。

并且在运行它时触发GetCurrentThreadStackLimits得出以下内容：

上图显示了堆栈的下限和上限，要从这里获取指令指针控件，我们就必须在堆栈中找到结构化的异常处理程序链，并修改一个条目，然后引发异常。在执行此操作时，请务必记住，由于Windows 10启用了SEHOP。因为SEH指针不受CFG保护，这些操作会绕过CFG和RFG，这一切都在文件Getting_Control.html中实现。

为了执行此操作，我们需要在堆栈上找到SEH链，泄漏堆栈限制的结构化异常处理程序链如下所示。

很明显，在调试异常发生时，如果问题不是固定的，那么所有使用jscript9的五个结构化异常处理程序指针都将被使用，而MSHTML！_except_handler4似乎永远处于调试异常的死循环中。因此，如果我们可以修改5个JavaScript异常处理程序中的任何一个并触发异常，我们都将获得可以控制的指令指针。在我们原来的结构化异常处理程序的修改中，整个结构化异常处理链都会被堆栈缓冲区溢出所覆盖，但由此带来的问题便是SEHOP会被触发，因此我们只需要修改其中一个异常处理程序的结构化异常处理记录，并同时保持NSEH的完整性。因此，修改必须精确，且结构化异常处理记录的堆栈地址必须泄漏。要让泄露发生，我们就必须对堆栈进行扫描并查找到结构化异常处理链，在确定我们已经找到之后，我们就可以验证最终的异常处理程序是ntdll！FinalExceptionHandlerPadXX。由于ntdll！FinalExceptionHandlerPadXX函数在应用程序重新启动时发生更改，因此泄漏要分两步执行，首先找到正确的最终异常处理函数，然后再找到结构化异常处理链。为了获得第一个泄漏，我们要在ntdll！_except_handler4中搜索堆栈，因为只有在ntdll！_except_handler4的上下搜索中才会碰到第一个泄漏。

接下来，便是找到ntdll！_except_handler4的地址，但是这是很容易的，因为可以从任何受CFG保护的函数中找到ntdll.dll的指针，并且还包含一个间接调用。 CFG验证包含对ntdll！LdrpValidateUserCallTarget的调用，并且由于jscript9.dll受CFG保护，任何间接调用的函数都包含直接指向ntdll.dll的指针。在TypedArray对象的虚拟函数表的偏移0x10处，就存在一个这样的函数。

使用序列化执行权限，可以通过以下函数找到指向ntdll.dll的指针。

我们可以在ntdll.dll的指针中通过使用序列化执行权限来搜索地址签名或哈希值来找到_except_handler4的地址， _except_handler4看起来像这样：

起始的0x10字节始终保持不变，并且非常独特，因此它们可以在始终被用作无冲突的哈希搜索。

该函数可以将指针作为参数指向ntdll.dll，一旦我们有了函数指针，我们可以搜索栈了。

在这个地址，我们可以得到以下内容。

这意味着之前的双字可能会被读取并被包含在其中：

如上图所示，最终的异常处理函数指针已经被找了出来。

接下来，我们该开始进行第二阶段的泄漏了，不过这次我们寻找的异常处理程序来自于jscript9.dll，所以它的函数指针必须位于PE的代码段内，以下这些地址就是来自PE头的DLL。

现在，从顶部和底部开始搜索堆栈，查看堆栈的所有内容。算法原理如下：

· 如果双字低于0x10000000，则函数指针就不在jscript9.dll内，因此我们要跳转到下一个双字；

· 如果双字高于0x10000000，则检查函数指针是否在jscript9.dll的代码段内，如果是，则堆栈上双字是指向堆栈的指针；

· 如果前面进展顺利，则很可能是我们正在寻找的结构化异常处理程序，所以我们尝试并遵循堆栈指针的原则，来检查我们是否以最终的异常处理程序来结束；

· 如果其中一个指针不再指向堆栈或者需要超过8个引用，那么它肯定不是结构化异常处理链；

我们在测试中，也是第一次找到一个指向jscript9.dll的指针，其中双字刚好是一个堆栈指针，由于它是结构化异常处理链，所以算法运行速度很快。

使用这个算法意味着可以精确地修改结构化的异常处理程序记录，而不会中断下一个异常处理程序的指针，从而实现绕过SEHOP。

最后，触发异常，以获取可控制的指令指针。

运行结果如下：

可以看出，调试器捕获到了异常运行，并继续用0x42424242对指令指针进行修改。这说明了这种技术是可以绕过CFG来获得执行控制的，而且它同样能绕过Return Flow Guard来实现执行控制。

详细的代码请点击这里。