Board logo

标题: [转载]OLEAUT32.dll模块中处理类型库的相关函数可导致代码执行 [打印本页]

作者: 17713942    时间: 2010-8-4 11:08     标题: [转载]OLEAUT32.dll模块中处理类型库的相关函数可导致代码执行

刚下载完几部不错的片子,但是考虑到做人要讲信用,所以我还是坚持写完了这篇Blog。

这个小问题是2008年初发现的,报告给微软后,微软认为这并不是一个安全漏洞——或者说,这并不是一个值得修复的安全漏洞。所以,以下以“小问题”来称呼这个小问题。

接触过COM的朋友,对类型库(TypeLib)一定不陌生。类型库由接口描述语言(IDL)编写,类似下面这样:

// TLBTest.idl
[
uuid( 11111111-1111-1111-1111-111111111111 ),
version( 1.0 ),
helpstring( "TLBTest COM" )
]
library TLBTest
{
importlib( "stdole2.tlb" );

[
uuid( 22222222-2222-2222-2222-222222222222 ),
//helpstring( "struct TLBTestVtbl" ),
dual,
oleautomation,
hidden,
nonextensible
]
interface TLBTest_ : IDispatch
{
};

[
uuid( 33333333-3333-3333-3333-333333333333 ),
//helpstring( "struct TLBTest" ),
appobject
]
coclass TLBTest
{
[default] interface TLBTest_;
}
}

把上面的TLBTest.idl用midl.exe编译,生成TLBTest.tlb。这就是一个类型库。类型库可以独立存在,也可以捆绑在PE文件中。

在Windows系统中,处理类型库的函数都封装在系统目录下的OLEAUT32.dll模块里。当你使用COM(譬如ActiveX控件)时,就会和这些函数打交道。

打开前面编译生成的TLBTest.tlb,可以看到偏移0x1A8处的4字节是0。当类型库被映射到内存中后,这四个字节会用来存放一个类实例指针。四个字节的0实际上是把这个指针初始化为NULL。

事实上,当类型库被加载到内存中后,OLEAUT32.dll模块中的代码会先判断一下这个指针是不是NULL:

775F4D8C    mov     edi, [esi+5Ch]   ;
775F4D8F    test    edi, edi         ; 如果0x1A8处不为0
775F4D91    jnz     loc_775F4E6E
775F4E6E loc_775F4E6E:
775F4E6E    mov     ecx, edi         ;
775F4E70    call    CTypeInfo2::InternalAddRef(void)

如果这四字节不为0,就会直接将它作为类实例指针进行一系列的函数调用。类似这样:

7760C1F0    mov     eax, [edi]
7760C1F2    lea     ecx, [ebp+var_2F0]
7760C1F8    push    ecx
7760C1F9    push    [ebp+lpSubKey]
7760C1FF    push    edi
7760C200    call    dword ptr [eax+10h] ; OLEAUT32!CTypeLib2::GetTypeInfo()
7760C203    mov     ebx, eax
7760C205    test    ebx, ebx
7760C207    jl      loc_7760C13C
7760C20D    mov     eax, [ebp+var_314]
7760C213    test    eax, eax
7760C215    jnz     loc_776134EB
7760C21B    mov     eax, [ebp+var_2F0]
7760C221    mov     ecx, [eax]           ; eax = 0x1A8处的值+4
7760C223    lea     edx, [ebp+var_334]
7760C229    push    edx
7760C22A    push    eax
7760C22B    call    dword ptr [ecx+0Ch]  ; bingo

那么这个小问题影响哪些软件呢?可以说,凡是用了OLEAUT32.dll中那些类型库函数的软件,都受影响。但是对大多数软件来说,这并不算太大的问题。因为当其处理某类型库时,也就意味着执行了类型库对应的COM代码。

譬如说,你在系统上安装了Real Player,那么当你用任何软件播放Real格式的媒体文件时,实际上都处理了Real Player的类型库。理论上,如果这个类型库是特殊处理过的,就可能使你执行任意代码。但是别忘了,系统处理Real Player的类型库是为了执行播放器的代码。如果有人想构造一个恶意的Real Player,那么直接修改代码本身是更简单的办法。

所以说,这个小问题,对一般人影响并不大。

但是,假如你从事的是软件方面的技术工作,经常编译一些网上看到的代码,或者做一些逆向分析的工作,那么这个小问题也许就不那么小了。

很多开发工具都会处理那些并没有安装在系统上的COM中的类型库。也就是说,这些工具仅仅只是“查看”COM的类型库。而现在,当你认为自己只是在“查看”一个类型库时,就可能已经执行了代码。

VC中带的OLEView工具、VC编译器本身(cl.exe及其处理CPP的相关模块)、eXeScope或者其它任何一个能查看PE资源中类型库信息的工具、Total Commander的Fileinfo插件(http://physio-a.univ-tours.fr/tcplugins/FILEINFO.htm),至少这些工具都可以触发这个小问题。

需要解释一下的是,VC编译器为什么会在受影响的列表里。VC编译器支持直接从类型库中“import”获取接口定义的工作方式。也就是说,当我们在任意一个CPP文件中,插入一行:

#import "\\192.168.0.254\Daddy\TLBTest.tlb"

这样,编译器在编译时就会试图从192.168.0.254这台主机上的Daddy共享目录下读取并解析TLBTest.tlb。

由于这是系统库的问题,和任何软件本身无关。所以它影响至少VC 6之后所有版本的VC。又由于至少Windows 2000之后所有Windows的OLEAUT32.dll都有这个问题,所以它基本上影响所有用VC的人。想象一下:你从某网页找到一段能解决你问题的代码,复制下来,一编译,啪~。

这是一个控制指针的小问题,对这类问题一般首先想到的是Heap Spray。然而,在VC编译器这类软件中是没法Heap Spray的(我和同事测试过多种方案,都没有成功,当然也许还有我们没有想到的方法)。

所以后来用了一种不依赖Heap Spray的方法,也可以几乎百分之百成功利用。不过对软件的大版本号略有依赖。以VC为例,VC 6的利用是一个代码,VC 2005和VC 2008是另一个。也许还有人记得这篇Blog:/Article/200910/41773.html,其实讲的就是这个小问题的利用。

顺便多说一句:对部分类型的漏洞来说,DEP+ALSR+SEHOP虽然还不能说完全是浮云,起码也是部分浮云了。




欢迎光临 【3.A.S.T】网络安全爱好者 (http://3ast.com/) Powered by Discuz! 7.2