微软Win8SafeLink安全机制.pdf

攻破微软win8 safelink安全机制 传统利用手段 vs 新的防护方法 peter hlavat eset软件工程师 兴趣: 漏洞研究 漏洞防护 内核开发 bootkit研究 恶意代码检测和移除算法 zer0mem 博客 : http:/zer0mem.sk/ 我是谁 正如nico在他的演讲中提到的，碰巧的持续的威胁，传统的堆利 用正在消失 windows版本+ 攻击难度+ 弱实现= 机理利用之处 introduction windows 内存管理 我们来看一下算法 快速看一下 rtlpallocateheap freelists link搜索算法 确实，在算法中很明显有一些安全加强之处 头部进行了验证和编码 rtlpanalyzeheapfailure 安全上链 code1 = _heap.encodeflagsmask ? code1 _heap.encoding.code1 : code1 valid = code1.flags (byte)code1.size (code1.size 8) = code1.smalltagindex size = code1.size _heap.encodeflagsmask 初始设置为 0x100000 _heap.encoding.code1 设置为随机值 头部的验证和编码 cs:rtlpdisablebreakonfailurecookie x64系统默认使用，但x86不是 常用的是x86的windows程序 第三方程序又怎么样呢？ rtlpgetmodifiedprocesscookie 调用 ntqueryinformationprocess i. rtlpanalyzeheapfailure heap_entry.flink.blink != heap_entry.blink.flink | heap_entry.flink.blink != heap_entry 非常简单的检测是吧？ ii.安全上链 rtlpheapalloc如何检索释放列表 freelistssearch 漏掉了验证检查 rtlpanalyzeheapfailure 结果是：是否结束掉程序？第三方程序如何处理？ safelink检查 实现是否足够智能？ 问题 ? 利用1 给我看看你的功夫: 技术方案 构建自己的堆 思路 在编码逻辑下做文章在编码逻辑下做文章 heap_entry.size 的下边界: 有意思的测试: _heap.encodeflagsmask & heap_entry.code1 如果没有匹配，那么就不是异或！ 大小为 0 如何? implementation shortcut 在编码逻辑下做文章在编码逻辑下做文章 heap_entry.size 的上边界: 有意思的异或值 : _heap.encoding.code1 设置为随机值 这个案例下：越多的随机化=越可能被猜测 if (heap_entry.size set to 0101010101010101b) then (_heap.encoding.code1 heap_entry.size) 很可能生成很大的数值 实现简要 在编码逻辑下做文章在编码逻辑下做文章 heap_entry.size的上边界（2） : 基于异或 在释放列表中有两个heap_entry的数据块 第一个设置heap_entry.size为0x8000 第二个设置heap_entry.size为0x0 在异或之后，其中一个heap_entry.size肯定将会等于 0x8000这样大的数值 implementation shortcut 构建自己的堆 实现 看 看- safelink 检查 ? 攻击! safelink 检测 堆喷射伪造链满足条件 rtlpanalyzeheapfailure? 我是第三方程序 问题： 只能工作在x86程序上 在win7sp1上已经修复 结果 ? 足够好足够好? 不是不是. 能改善吗? 看上去相似? 头部进行了验证和编码 rtlpanalyzeheapfailure 安全上链 快速看一下 rtlpfreeheap freelists link搜索算法 heap_entry.blink.flink != heap_entry 安全链接, 改变了 !? 再一次，这里不需要验证 性能 vs 安全？ rtlpfreeheap 在 freelists 寻找 previous idea imporving what do you think happen with valid chunk, with size is bigger than size of already overwritten heap_entry, when it is attempted to be freed ? 你认为，当一个大小大于已经被覆盖的heap_entry的有效数据块被 释放时会发生什么？ 以前的想法-改进中 利用 2 -表演时间 改进, 改进, 成功 和第一个攻击相同： 堆喷射攻击 sizeof(heap_entry) + sizeof(list_entryflink) 溢出, 导致 freelist中_heap_entry被覆盖 第二个攻击的特点: 强制应用程序释放已经使用的“大小正确的”内存内存泄露 读写我们堆喷射过的内存重新链接 前提 攻击! 利用的图示- 初始 利用的图示- 堆喷射 利用的图示- 覆盖 利用的图示 free(*) 成功率 100% 结果 现场演示 win7 sp1 总结: 防御机制的好坏取决于最弱的那一点！ 实现最优雅的方法，同时覆盖到所有需要的代码中 安全的环境高于速度和性能的需求 结束 2年前报告给微软 但是仍然存在于win7 sp1，甚至win8cp中仍然可用！ 在win8的最终发布版中补上了！ freelist搜索算法现在验证了每一个heap_entry 其他技术信息 现场演示 win8 cp, ie10 参考 brett moore : exploiting freelist0 on xp service pack 2 /secdocs/windows/protection/bypass/exploiting%20freelist%5b0%5d%20on%20xp%20service %20pack%202.pdf chris valasek : understanding the low fragmentation heap /understanding_the_lfh.pdf brett moore : heaps about heaps /vuln-dev/2008/jul/0 alexander sotirov : heap feng shui in javascript /presentations/bh-europe-07/sotirov/presentation/bh-eu-07-sotirov-apr19.pdf nico waisman : aleatory persistent threa