office-栈溢出漏洞简单汇总

CVE-2017-1182

关键词：

rtf，公式编辑器，拷贝未检测长度，ACTIVEX控件解析

漏洞原理：

在读入公式的Font Name数据时，在将Name拷贝到一个函数内局部变量的时候没有对Name的长度做校验，从而造成栈缓冲区溢出

漏洞函数：

漏洞存在于EQNEDT21.EXE公式编辑器的sub_41160F函数中，我们将其拖进IDA，找到漏洞点，可以看到伪代码如下，这里没有对长度进行检验就直接进行复制操作，而这个a1参数是我们可以控制的，所以本质上就可能产生一个栈溢出漏洞

那么a1这个数据是从哪来的呢？
IPersistStorage::Load方法的主要用途是用来读入ole数据，在EQNEDT32.EXE中实现该方法后，即可被调用以读入MathType对应的ole数据，该函数的核心逻辑是打开并读入一个叫做“Equation Native”的流的数据。
Equation Native 由几个成员组成
Equation Native = EQNOLEFILEHDR + MTEF Header + MTEF Byte Stream

其中 MTEF Byte Stream 结构如下

这里我们主要关注的是其中的 FONT 结构，也就是漏洞点，结构如下

struct stuFontRecord {
　　BYTE bTag;        // 字体文件的tag位0×08
　　BYTE bTypeFace;   // 字体风格0x5a
　　BYTE bStyle;      // 字体样式0x5a
　　BYTE bFontName[n] // 字体名称,以NULL为结束符,漏洞点
};

而字体名称就是实现栈溢出的地方。也就是伪代码中的a1

CVE-2012-0158

关键词：

长度效验错误，rtf，OLE，ACTIVEX控件解析问题

漏洞原理：

这个漏洞的根本原因在于MSCOMCTL.OCX在解析ListView(当然，不止这一个控件)的“Contents”流时，在经过层层校验后读入“CObj”对象的数据时，在最后的长度校验中因为不小心将小于等于号写成了大于等于号而导致的一处栈溢出 。

这个漏洞的根本原因在于MSCOMCTL.OCX在解析ListView(当然，不止这一个控件)的“Contents”流时，在经过层层校验后读入“CObj”对象的数据时(从图20中可以发现，漏洞触发前的数据校验不可谓不多)，在最后的长度校验中因为不小心将小于等于号写成了大于等于号而导致的一处栈溢出

漏洞函数：

漏洞存在于MSCOMCTL.OCX模块的sub_275C89C7中。执行完275C876D，返回到275C89C7函数，执行完再返回时EIP指向41414141产生程序崩溃。用IDA打开MSCOMCTL.OCX，直接跳转到我们的漏洞函数275C89C7，可以看到触发漏洞的275C876D函数其实是叫CopyOLEdata。其中传入了在EBP-8位置的参数v7、字符串bstrString，以及一个通过if判断后大于等于8的dwBytes。触发条件为首先从bstrString中读取0xC字节到临时变量v5中，并且判断v5的前四字节是否为Cobj以及dwBytes是否大于等于8。跟进触发漏洞的函数，可以看到会有一个qmemcpy函数(也就是在OllyDbg里看到的那条REP MOVS指令)将刚刚的bstrString复制dwBytes的长度到高港的EBP-8的位置，发生了栈溢出。

int __stdcall sub_275C89C7(int a1, BSTR bstrString)
{
    BSTR v2; // ebx
    int result; // eax int
    v4; // esi
    int v5; // [esp+Ch] [ebp-14h]
    SIZE_T dwBytes; // [esp+14h] [ebp-Ch]
    int v7; // [esp+18h] [ebp-8h]
    int v8; // [esp+1Ch] [ebp-4h]
    v2 = bstrString;
    result = sub_275C876D((int)&v5, bstrString, 0xCu);
    if ( result >= 0 )
    {
        if ( v5 == 1784835907 && dwBytes >= 8 )//大于8溢出
        {
            v4 = sub_275C876D((int)&v7, v2, dwBytes);//这儿发生的栈溢出
            if ( v4 >= 0 )
            {
                if ( !v7 ) goto LABEL_8;
                bstrString = 0;
                v4 = sub_275C8A59((UINT)&bstrString, (int)v2);
                if ( v4 >= 0 )
                {
                    sub_27585BE7(bstrString);
                    SysFreeString(bstrString);
                    LABEL_8:
                        if ( v8 ) v4 = sub_275C8B2B(a1 + 20, v2);
                        return v4;
                }
            }
            return v4;
        }
        result = -2147418113;
    }
    return result;
}

CVE-2011-0104

关键词：

.xlb，复制数据和长度由POC读取，EXCEL

漏洞原理：

Excel在解析XLB文件中的TOOLBARDEF Record时存在的栈溢出漏洞 漏洞利用了不安全的函数 memcpy，而函数的两个参数一个是复制源数据的大小，一个是复制的地址都是从 POC 中读取的，没有做任何的过滤，最后导致了栈溢出的发生 。

漏洞函数：

ida看一下是sub_300DE7EC函数中复制出的问题， 这里复制来源是data段的一个地址3088EC40，长度是v7。

从 V7 入手，层层溯源，发现是这个函数传入的第三个参数

第三个参数又是 sub_3008945F 中获取的

进入这个函数看一下，发现这个函数是读取 POC 上的数据

CVE-2018-0802

关键词：

拷贝长度未效验，RTF文件， 公式编辑器，ACTIVEX控件解析

漏洞原理：

程序在初始化一个LOGFONT结构体时, 未对用户输入的字体名进行长度校验,直接进行copy发生溢出

漏洞函数：

这个漏洞是在微软完成CVE-2017-11822修复后又在差不多的位置找到另外一个能够利用的点。

CVE-2018-0798

关键词：

公式编辑器，未进行长度效验，rtf，ACTIVEX控件解析

漏洞原理：

程序没有正确的处理内存中的对象，Matrix record对象的部分会被复制到栈缓存中，但没有进行适当的范围检查。解析到rows与cols成员时没有进行额外的长度校验，通过构造恶意数据，可以任意指定后面读入的row_parts和col_parts长度，从而导致栈溢出。这允许攻击者修改保存的返回地址、控制指令指针。远程攻击者可借助特制的文件利用该漏洞执行任意代码。

漏洞函数：

sub_443F6C函数(无ALSR)：

int __cdel ReadPartLineTypes(__int16 a1,char *a2)
{
	__int16 v2;//STOC_2@2
	int result;//eax@2
	__int16 v4;//[sp+18h][bp+8h]@1
	
	v4 = (2 * a1 + 9) >> 3;
	while(1)
	{
		v2 = v4--;
		result = v2;
		if(!v2)
		break;
		*a2++ = inc_and_get_byte_from_counter_offset();
	}
	return result;
}

该函数在复制数据到栈上时，没有对v4的长度进行校验，只有当v2=null时才会停止复制。构造数据，即可导致栈溢出，覆盖EIP，执行控制流。

执行流程如下：

1. sub_416352 函数：从样本中取出 Matrix 偏移地址 +B 的数据用来控制循环读取数据的次数，然后将其传递给sub_443F6C函数。
2. sub_443F6C 函数：将之前取出的循环次数放入 eax 中，之后进行 (eax + 9) >> 3 的运算，运算完成之后再调用 sub_416352 函数进行复制与循环判断。
3. sub_416352 函数：获取需要复制到栈上的数据（Matrix 数据偏移 +D），之后通过 mov [ecx]，al 指令将获取到的数据复制到栈中，复制大小为一个字节，完成之后判断循环次数是否为 0，为 0 则跳出循环。

CVE-2010-3333

关键词：

RTF，复制内存过大，pFragments，控制字解析

漏洞原理:

​ Microsoft Office Word 2003中的MSO.dll库在解析RTF文档时完全信任其数据，未做任何检查便将数据复制到栈中，由于Word中的RTF分析器在解析文档绘图pFragments属性值时，没有正确计算属性值所占用的空间大小，只要复制的数据大小超过0x14即可覆盖到函数返回地址，进而控制程序的执行流程，用于执行恶意程序。

漏洞函数：

30ED442C的位置为拷贝的地址

rep movs dword ptr es:[edi],dword ptr [esi]

esi的内容就是在rtf文件中acc8后面的乱码。也就是说要把esi中的这些乱码复制到edi对应的地址中，复制多少呢？rep的循环次数由ecx确定，ecx是0xc8a8/4（shr ecx,2），远大于edi对应的0x10大小（ebp-0x10），由此造成栈溢出。

总结

1.office栈溢出漏洞大多以rtf格式为载体。

2.大多栈溢出问题存在于ACTIVEX控件解析问题。

3.office栈溢出漏洞基本上都为拷贝时长度未效验或者长度由poc控制。