IE浏览器缓解技术逆向初探

阅读量    50104 |   稿费 400

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

作者:dwfault@野火研习社

预估稿费:400RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿

 

前言

浏览器中的UAF类漏洞触发时,通常用“exploit-friendly”对象占位之前释放的内存空间,通过数组下标索引即可读写此内存区域的对象,控制内存中的对象虚函数调用以执行流程劫持。虚函数调用本质上是通过函数指针进行的,往往形如“call register”或“call [register + offset]”,因此也被称为间接调用。

 

2014年6月,微软在浏览器产品Internet Explorer中应用堆隔离技术(Isolated Heap),把漏洞多发的对象与“exploit-friendly”对象分配在不同的堆空间;2014年7月微软在IE浏览器中加入延迟释放技术(Delayed Free),其主要流程如下:对象释放时不立即释放堆块,而是加入等待列表中;当内存分配有压力时,从栈中检查是否存在对内存空间的引用,不存在时将堆块释放;针对劫持间接调用的攻击技术,微软在Windows 10上实现了粗粒度的控制流保护技术(Control Flow Guard, CFG)。堆隔离、延迟释放、控制流保护技术使得传统的基于占位的利用技术发生变化,本文就来对这些缓解技术进行逆向初探,分析环境为Windows 10 14393 32bit IE 11,主要分析对象涉及mshtml.dll、msvcrt.dll、ntdll.dll等。

一、堆隔离技术

在mshtml!DllMainStartup函数中,有:

call        ds: __imp__GetProcessHeap@0

mov      ecx, eax

mov      _g_hProcessHeap, ecx

call        ?RegisterHeap@MemoryProtection@@YGXPAX@Z ;

mov      _g_hIsolatedHeap, ecx

当mshtml.dll被加载进入浏览器内存时,DllMainStartup函数首先被调用,初始化全局变量_g_hProcessHeap、_g_hIsolatedHeap,全部赋值为GetProcessHeap API的返回值,即首先将隔离堆的句柄初始化为进程默认堆。

mshtml!DllProcessAttach函数中有:

push      ebx

push      ebx               ; dwInitialSize

push      ebx               ; flOptions

call        ds:__imp__HeapCreate@12 ;

mov      _g_hIsolatedHeap, eax

这段代码创建了新的堆,随后为全局变量_g_hIsolatedHeap重新赋值。从这里开始隔离堆被创建。之后在隔离堆上分配对象时,设置HeapAlloc的参数为_g_hIsolatedHeap。下面代码已经简化:

mov      ecx, _g_hIsolatedHeap

…

call        ds:__imp__HeapAlloc@12

按照同样的方法对jscript9.dll中的内存分配进行逆向分析。分析发现,一部分对象分配在系统堆上;大多数对象使用jscript9!HeapAllocator::Alloc分配,该函数实际是对malloc函数的封装,malloc函数位于msvcrt.dll中,跟踪进入该模块,发现这些对象分配在__crtheap中。

 

查看全局变量_g_hIsolatedHeap的交叉引用,可得到分配在隔离堆的对象类型,其中包括DOM元素(CElement及其派生类)、DOM树节点(CTreeNode)、DOM树节点标记(CTreePos)、结构化标记(CMarkup)等。堆隔离技术使可用于内存占位的对象种类减少,因此占位难度增加,漏洞利用的难度增加。

二、延迟释放技术

mshtml.dll模块下的MemoryProtection命名空间实现了多个延迟释放技术相关的类,因此延迟释放技术也被称为MemoryProtection。CMemoryProtector是命名空间中的核心类,浏览器进程的每个线程维护一个该类的实例,该实例的索引存储在线程局部存储TLS中,总大小为0x1020字节,其结构如下:

class      CMemoryProtector

+00       void * SBlockDescriptorArray

+04       DWORD TotalSize

+08       DWORD NumberOfUsed

+0c       DWORD NumberOfTotal

+10       BOOL IsSorted

+14       BOOL IsForceMarkAndReclaim

+18       DWORD StackHighAddress

+1c       DWORD StackMarkerAddress

+20       DWORD SAddressFilter[512]

其中的SAddressFilter是一个bitmap,用来指示SBlockDescriptorArray中的堆块是否存在引用。SBlockDescriptor是SBlockDescriptorArray中的元素,大小为8字节,用以存储堆块的地址和大小。其结构如下:

struct    SBlockDescriptor

+00       void *pAddress

+04       DWORD nSize

SBlockDescriptorArray表示等待列表,对象释放后堆块添加进该列表,以后再释放堆块。等待列表在初次分配时大小为0x8000字节,可以存放0x1000个SBlockDescriptor,NumberOfTotal表示等待列表的总容量,初始值为0x1000;NumberOfUsed表示已存储的堆块个数,初始值为0。当有新的堆块添加到SBlockDescriptorArray时,NumberOfUsed增加;当NumberOfUsed与NumberOfTotal相等时,说明SBlockDescriptorArray已满,此时调用HeapReAlloc重新分配SBlockDescriptorArray,大小翻倍。

图1 延迟释放技术相关函数调用关系

被保护的对象在释放时,不直接调用Windows API HeapFree,而是调用MemoryProtection::HeapFree。该函数检查进程保护策略,包括是否启用延迟释放技术的保护等,若保护未开启,调用Windows API HeapFree直接释放堆块;否则调用CMemoryProtector::ProtectedFree。

 

CMemoryProtector::ProtectedFree函数调用的核心函数是ReclaimMemory,此外调用有SBlockDescriptorArray::AddBlockDescriptor、SAddressFilter::AddBlock、memset。

ReclaimMemory用于检查等待列表中的堆块。首先检查CMemoryProtector的TotalSize域,该值表示已经添加进等待列表的堆块总大小,当TotalSize小于等于0x186a0(100000)字节时不做处理,否则调用MarkBlock、ReclaimUnmarkedBlocks函数,这两个函数实现了标记清除式垃圾回收算法。算法首先从栈内存中查找堆块的引用,标记存在引用的堆块;然后释放未标记的堆块,为已标记的堆块去除标记以供下次检查。最后调用memset把堆块内容覆写为0。

 

SBlockDescriptorArray::AddBlockDescriptor用于在等待列表中增加堆块;SAddressFilter::AddBlock用于进行bitmap的更新。

图2展示了延迟释放技术相关代码的整体流程图:

图2 延迟释放技术相关代码流程图

可将延迟释放技术总结如下:对象释放时不立即释放堆块,而是加入等待列表中,同时将堆块内存覆写为0;当列表标示的堆块总大小达到100000字节时,从栈中检查是否存在堆块的引用,若不存在引用则将堆块释放。

 

延迟释放技术对基于占位的UAF漏洞利用具有有效的遏制作用。但由于IE浏览器采用保守垃圾回收算法,延迟释放机制存在严重缺陷:

保守垃圾回收算法无法区分指针和数据,攻击者可以用Array等数据结构在栈中伪造堆块的指针,使伪造指针所指向的堆块不能被释放;以侧信道攻击配合,攻击者迭代地把指针置零可将MemoryProtection用作Oracle,询问进程内存空间是否可用;用这种方法将动态库模块加载到一个确定的地址,该地址就是本次置零的指针值。如图3所示,研究者利用延迟释放技术将Windows.data.pdff.dll加载到确定的地址:

图3 利用延迟释放技术绕过ASLR技术示意图

三、控制流保护技术

Visual Studio 2015及之后的版本支持CFG,相关编译参数为“/guard:cf”。编译时,编译器扫描所有的间接调用,在调用之前插入语句调用检查函数;且将潜在的间接调用的目的函数地址对齐到0x10字节,即函数地址值可整除16。

 

链接过程中,模块的PE文件节区结构体IMAGE_LOAD_CONFIG_DIRECTORY末尾添加有GuardFlags和GuardCFFunctionTable、GuardCFFunctionCount等项。其中GuardCFFunctionTable是一个表,反汇编时该函数被识别为___guard_fids_table,表中以RVA形式存放函数指针,用1字节存放SuppressedFlag,每个表项5字节,GuardCFFunctionCount表明该表的容量。

 

例如,某dll模块定义导出函数normal_function、sensitive_function,假设要求sensitive_function不能被间接调用,可在函数声明时添加“guard(suppress)”关键字。编译完成后,节区包含GuardCFFunctionTable如下:

 

10001040    _sensitive_function

01

10001070    _normal_function

00

100010C0   @__security_check_cookie@4

00

100013F0    __DllMainCRTStartup@12

00

对于_sensitive_function,SuppressedFlag值为1,标示为禁止间接调用;其他函数对应的SuppressedFlag值为0,标示为允许间接调用。该模块被加载进入进程内存空间后,进程bitmap添加对应的DWORD值来标示其中函数是否被允许间接调用。

 

程序执行过程中,exe和dll模块中的代码在执行间接调用前会先调用函数__gurad_check_icall,其中EDI寄存器存放实际调用的函数,调用之前拷贝到ECX寄存器传入__gurad_check_icall函数进行检查:

 

mov      ecx, edi

call        _guad_check_icall

call        edi

另外,有些函数中的间接调用会检查栈顶在调用前后是否发生变化:

 

mov      ebx, esp

mov      ecx, edi

call        _guad_check_icall

call        edi

cmp      ebx, esp

jz          loc_continue:

mov      ecx, 4

int  29h

静态分析时,函数_guad_check_icall在文件中指向无意义的函数,只包含RETN指令以兼容老版本的操作系统;在被加载进入进程时该函数被动态插装,指向的汇编代码横跨连续的三个函数:

 

ntdll!LdrpValidateUserCallTarget:

mov      edx,dword ptr [ntdll!LdrSystemDllInitBlock+0x60]

mov      eax,ecx

shr        eax,8

ntdll!LdrpValidateUserCallTargetBitMapCheck:

mov      edx,dword ptr [edx+eax*4]

mov      eax,ecx

shr        eax,3

test              cl,0Fh

jne        ntdll!LdrpValidateUserCallTargetBitMapRet+0x1

bt          edx,eax

jae         ntdll!LdrpValidateUserCallTargetBitMapRet+0xa

ntdll!LdrpValidateUserCallTargetBitMapRet:

ret

or          eax,1

bt          edx,eax

jae         ntdll!LdrpValidateUserCallTargetBitMapRet+0xa

ret

…

ntdll!LdrpValidateUserCallTargetBitMapRet+0xa

call        ntdll!RtlpHandleInvalidUserCallTarget

本段代码中ntdll!LdrSystemDllInitBlock+0x60存放bitmap基地址的指针,该bitmap在大多数情况下是只读的。bitmap中的每个DWORD标示0x00-0xff范围内256个地址的合法性。例如,对于10001070处的_normal_function函数,地址的LSB为0x70,bitmap有对应10001000~100010FF范围的DWORD,该DWORD第14位为1,标示该函数是合法的。

 

对于每个DWORD,偶数位可以为0或1,标示地址LSB为00、10、20、30、40、50、60、70、80、90、A0、B0、C0、D0、E0、F0处函数的合法性;每个DWORD的奇数位与地址LSB的其他值构成一对多的关系,一般均为0,表示这些地址全部非法。下表举例展示内存地址地址LSB与bitmap比特位的对应关系:

表1 内存地址LSB与bitmap比特位的对应关系示例

浏览器进程中间接调用的黑白名单由加载到进程的不同模块确定;在进程中也可以直接调用SetProcessValidCallTargets来修改黑白名单;进程代码如果调用Window API GetProcAddress,该API也会修改bitmap以标示对应函数为合法。

 

CFG技术通过bitmap维护各模块中间接调用地址的黑白名单。由于进程bitmap不存在0x0c0c0c00~0x0c0c0cff所对应的DWORD值,CFG技术使堆喷射技术常用的0x0c0c0c0c等地址为非法地址;间接调用的目标为函数内部的情况也不合法,因为该地址不在bitmap标识的白名单之内。

 

CFG技术主要保护间接调用。它不是为控制流完整性而设计,也不能保证控制流完整性。通过上述分析可知该技术有如下缺陷:

不保护栈上的返回地址和其他函数指针(如SEH)。

不保护call [data]类型的函数调用。

CFG只提供粗粒度的保护。进程中的所有线程、模块查询同一个bitmap,因此共享相同的保护策略。由于兼容性原因,当不同模块的黑白名单冲突时只能将引起冲突的函数加入白名单。进程保护策略不好协调、不易确定,粗粒度的保护使CFG技术难以确保安全。

 

进程中,如果某dll模块未开启CFG,则该模块内的间接调用均不受保护;如果exe主模块未开启CFG,则保护完全失效。

CFG技术对于不改变程序执行流程的漏洞利用无保护作用。

目前CFG技术最严重的缺陷在于它提供保护的粗粒度。根据前述CFG的流程可以实现一个调试插件以枚举CFG检查为合法的目标函数【3】,发现IE 11浏览器进程中的合法目标函数不乏LoadLibrary、VirtualProtect、ProtectVirtualMemory等敏感API;另一方面存在2700个以上的DWORD的值为0xffffffff,意味着较老的模块中的任意地址均为合法地址;更重要的是,合法目标函数的总数在270000以上,理论上攻击者可以借鉴ROP技术实施代码重用攻击,将多个合法目标函数作为CFG gadget进行组合以绕过该技术的保护。

 

四、小结

新型缓解技术在UAF漏洞利用过程的各个阶段进行拦截,迫使高级漏洞利用技术也有所演进。

 

五、参考资料

Abusing Silent mitigations. Abdul-Aziz Hariri, Simon Zuckerbraum, Brian Gorenc

Cross The Wall-Bypass All Modern Mitigations of Microsoft Edge. Henry Li

https://github.com/dwfault/CFGValidEnum

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多