分析及防护：Win10 执行流保护绕过问题
原文地址：http://www.panshy.com/articles/201508/security-2512.html
Black Hat USA 2015正在进行，在微软安全响应中心公布的最新贡献榜单中，绿盟科技安全研究员张云海位列第6位，绿盟科技安全团队（NSFST）位列28位，绿盟科技 安全团队（NSFST）常年致力于发现并解决计算机以及网络系统中存在的各种安全缺陷。这篇《Windows 10执行流保护绕过问题及修复》是团队在此次大会上分享的主要内容
Content
- 执行流保护（CFG)
- CFG原理
- 绕过问题
- CustomHeap::Heap对象
- 绕过CFG
- 问题修复
- HeapPageAllocator::ProtectPages函数
- 修复机制
内容摘要
Black Hat USA 2015正在进行，在微软安全响应中心公布的最新贡献榜单中，绿盟科技安全研究员张云海位列第6位，绿盟科技安全团队（NSFST）位列28位，绿盟科技 安全团队（NSFST）常年致力于发现并解决计算机以及网络系统中存在的各种安全缺陷。这篇《Windows 10执行流保护绕过问题及修复》是团队在此次大会上分享的主要内容。
绿盟科技安全团队NSFST一直努力发现及修复计算机以及网络系统中存在的各种安全缺陷，如果您需要了解更多信息，请联系：
- 绿盟科技微博
- http://weibo.com/nsfocus
- 绿盟科技微信号
- 搜索公众号绿盟科技
执行流保护（CFG）
攻击者常常溢出覆盖或者直接篡改寄存器EIP的值，篡改间接调用的地址，进而控制了程序的执行流程。执行流保护（CFG，Control Flow Guard）是微软从Windows 8.1 update 3及Windows 10技术预览版开始，默认启用的一项缓解技术。这项技术通过在间接跳转前插入校验代码，检查目标地址的有效性，进而可以阻止执行流跳转到预期之外的地点， 最终及时并有效的进行异常处理，避免引发相关的安全问题。
这种思想及技术在业界有了较为成熟的应用，此次Windows 10将其引入，以便提高其安全性。但是绿盟科技安全团队（NSFST）在分析CFG的实现机制过程中，发现了CFG存在全面绕过的方法，随即向微软提报，并在随后的一段时间内，配合微软修复了这个问题。
CFG原理
在编译启用了CFG的模块时，编译器会分析出该模块中所有间接函数调用可达的目标地址，并将这一信息保存在Guard CF Function Table中。
同时，编译器还会在所有间接函数调用之前插入一段校验代码，以确保调用的目标地址是预期中的地址。这是未启用CFG的情况：
同时，编译器还会在所有间接函数调用之前插入一段校验代码，以确保调用的目标地址是预期中的地址。这是未启用CFG的情况：
这是启用CFG的情况：
操作系统在创建支持CFG的进程时，将CFG Bitmap映射到其地址空间中，并将其基址保存在ntdll!LdrSystemDllInitBlock+0x60中。
CFG Bitmap是记录了所有有效的间接函数调用目标地址的位图，出于效率方面的考虑，平均每1位对应8个地址（偶数位对应1个0x10对齐的地址，奇数位对应剩下的15个非0x10对齐的地址）。
提取目标地址对应位的过程如下：
- 取目标地址的高24位作为索引i；
- 将CFG Bitmap当作32位整数的数组，用索引i取出一个32位整数bits；
- 取目标地址的第4至8位作为偏移量n；
- 如果目标地址不是0x10对齐的，则设置n的最低位；
- 取32位整数bits的第n位即为目标地址的对应位。
操作系统在加载支持CFG的模块时，根据其Guard CF Function Table来更新CFG Bitmap中该模块所对应的位。同时，将函数指针_guard_check_icall_fptr初始化为指向 ntdll!LdrpValidateUserCallTarget。
ntdll!LdrpValidateUserCallTarget从CFG Bitmap中取出目标地址所对应的位，根据该位是否设置来判断目标地址是否有效。若目标地址有效，则该函数返回进而执行间接函数调用；否则，该函数将抛出异常而终止当前进程。
绕过问题
通过上面的原理分析，我们发现CFG的实现中存在一个隐患，校验函数ntdll!LdrpValidateUserCallTarget是通过函数指针_guard_check_icall_fptr来调用的。
如果我们修改_guard_check_icall_fptr，将其指向一个合适的函数，就可以使任意目标地址通过校验，从而全面的绕过CFG。通常情况下，_guard_check_icall_fptr是只读的：
但如果利用jscript9中的CustomHeap::Heap对象将其变成可读写的，那么就会出现问题了。
CustomHeap::Heap对象
CustomHeap::Heap是jscript9中用于管理私有堆的类，其结构如下：
CustomHeap::Heap::FreeAll 为每个Bucket对象调用CustomHeap::Heap::FreeBucket。
CustomHeap::Heap::FreeBucket 遍历Bucket的双向链表，为每个节点的CustomHeap::Page 对象调用CustomHeap::Heap::EnsurePageReadWrite<1,4>。
CustomHeap::Heap::EnsurePageReadWrite<1,4> 用以下参数调用VirtualProtect：
- lpAddress: CustomHeap::Page 对象的成员变量address
- dwSize: 0x1000
- flNewProtect: PAGE_READWRITE
将内存页面标记为PAGE_READWRITE， 这正是出现问题的关键地方。
绕过CFG
通过修改CustomHeap::Heap对象，我们可以将一个只读页面变成可读写的，从而可以改写函数指针_guard_check_icall_fptr的值。观察ntdll!LdrpValidateUserCallTarget在目标地址有效时执行的指令：
问题修复
绿盟科技安全团队（NSFST）发现这一问题后，立即向微软报告了相关情况。微软很快修复了这一问题，并在2015年3月发布了相关的补丁。在该补丁中，微软引入了一个新的函数HeapPageAllocator::ProtectPages。
HeapPageAllocator::ProtectPages函数
这个函数是VirtualProtect的一个封装，在调用VirtualProtect之前对参数进行校验，如下：
- 检查lpAddress是否是0x1000对齐的；
- 检查lpAddress是否大于Segment的基址；
- 检查lpAddress加上dwSize是否小于Segment的基址加上Segment的大小；
- 检查dwSize是否小于Region的大小；
- 检查目标内存的访问权限是否等于指定的（通过参数）访问权限；
任何一个检查项未通过，都会调用CustomHeap_BadPageState_fatal_error抛出异常而终止进程。
修复机制
CustomHeap::Heap::EnsurePageReadWrite<1,4>改为调用HeapPageAllocator::ProtectPages而不再直接调用VirtualProtect。
这里参数中指定的访问权限是PAGE_EXECUTE，从而防止了利用CustomHeap::Heap将只读内存页面变成可读写内存页面。
参考文献
1 MJ0011. Windows 10 Control Flow Guard Internals
http://www.powerofcommunity.net/poc2014/mj0011.pdf
[2] Jack Tang. Exploring Control Flow Guard in Windows 10
http://sjc1-te-ftp.trendmicro.com/assets/wp/exploring-control-flow-guard-in-windows10.pdf
[3] Francisco Falcón. Exploiting CVE-2015-0311, Part II: Bypassing Control Flow Guard on Windows 8.1 Update 3
https://blog.coresecurity.com/2015/03/25/exploiting-cve-2015-0311-part-ii-bypassing-control-flow-guard-on-windows-8-1-update-3/
[4] Yuki Chen. The Birth of a Complete IE11 Exploit under the New Exploit Mitigations
https://www.syscan.org/index.php/download/get/aef11ba81927bf9aa02530bab85e303a/SyScan15%20Yuki%20Chen%20-%20The%20Birth%20of%20a%20Complete%20IE11%20Exploit%20Under%20the%20New%20Exploit%20Mitigations.pdf