Question

我们简单的列出微软用于防止 Bitmap 泄露而实现的各种缓解机制，同时会说明它们分别该如何绕过。主版本在下面给出作为参考。

Windows 10 v1511

• 当前没有缓解措施。
• 利用从 PEB 中拿到的 GdiSharedHandleTable 句柄，找到正确的 GDI_CELL 结构体并读出 pKernelAddress，它揭示了 Bitmap SURFOBJ 的内核地址。可以在这里查看一个简单的示例 here .。

Windows 10 RS1 v1607

• 微软将 GDI_CELL 结构体中的 pKernelAddress 置空，老技术从此失效。
• 研究者发现了这样一些对象，它们和我们所垂涎的 Bitmap 放在相同的内存池中（分页内存池），且可以被泄露。可以通过利用 user32 来获取 gSharedInfo（一个全局变量）的地址，读取出 aheList HANDLEENTRY 数组的地址，找到正确的那个数组项并最终读出 phead 成员来获取该对象的内核地址。尽管我们无法直接读出 bitmap 对象的地址，但通过使用一个较大的尺寸(ensuring the would end up in a low entropy large pool) 精心构造/泄露对象并执行一个 UAF 风格的攻击，就可以使得 Bitmap 分配在被释放掉的原始对象的位置。可以在这里看到一个简单的示例 here 。

Windows 10 RS2 v1703

• 你不知道吗，微软把 phead 指针也置空了，上述方法也从此失效。
• 本文中我们将讨论如何利用用户映射的桌面堆来泄露 Windows 对象，和此前做法相似，执行一个 UAF 风格的攻击来重新溯源 Bitmap(primitive)！