这次分析了CVE-2012-0003 MIDI文件中存在的堆溢出漏洞，此次分析结合了《漏洞战争》以及VUPEN发布的关于该漏洞的介绍中的内容，从原理及利用两个角度对该漏洞进行了分析。

文章一开始对MIDI文件的结构进行了简单的介绍，之后根据IDA得到的伪代码，利用书中介绍的导图推算的方法确定了漏洞产生的原因。最后的漏洞利用部分花费了一些功夫，因为VUPEN中缺少具体细节，使用的利用代码并没有成功进行漏洞利用，书中也没有提到相关问题，所以文章中也涉及到我是如何对代码进行的修改，并分析了产生问题的原因。

MIDI文件是由块（chunk）组成的，每个块开头有4字节type信息及4字节length信息，length信息中表示的是该块之后的数据长度，即整个块的长度为length+8字节。

块分为两个类型：header chunk和track chunk，其基本组成如下图所示：

其中Delta-time+event表示一个MTrk event,它的个数不定，长度不定，所以画成了图中这样参差不齐的形式。

下面一个小节会根据具体文件来分析MIDI文件组成，这里先给出会涉及到的其他概念：

这种类型的数据信息用每个字节中的低七个比特表示，最高位为先。所有字节中，除最后一个字节外，其余字节的最高比特位置1，最后一个字节的最高比特位置0。由此确定该可变长度数据的终止位置。

在track trunk中，event又分为MIDI event、sysex event和meta-event。其中meta-event的结构如下：

它以0xFF开头，接下来是一个字节的type信息，之后的length信息是variable length quantity，然后根据length信息填入对应长度的bytes信息。

几个涉及到的type信息：

MIDI event(MIDI message)通常由1字节的状态码以及1~2个字节的数据信息组成:

在下面的实例分析中，主要涉及到的是Channel Message，涉及到的状态码为0x99、0x9F、0xB9和0xC9，其中的9和F表示是第九个channel。这里对这两个状态码做一下解释：

接下来根据书中提供的test_case.mid文件，实例讲解MIDI文件构成。test_case.mid内容如下：

按照2.1中给出的结构分解：

对于MIDI文件格式的理解就到这里，并没有覆盖的所有的信息，更多内容可以看参考资料1。除此之外，很多专业名词的解释我也不太清楚，但是对于漏洞分析本身没什么影响。

环境：Win XP SP3

IE:6.0.2900

接下来正式开始对漏洞进行分析调试，由于这是一个堆溢出漏洞，所以在调试之前先为IE开启页堆。

打开cve-2012-0003-ie6.htm文件，使用windbg附加，F5继续执行，然后在IE上允许脚本运行，程序中断：

看一下堆栈信息：

可以看到这个堆块的起始地址为0x2797ec00，大小为0x400，0x2797f019已经超过了这个堆块允许的最大地址范围0x2797f000，所以触发了异常。

再看一下函数调用情况：

所以目前想要确定的应该是0x2797f019这个地址是怎么得到的。找到WINMM.dll这个文件并在IDA中打开，找到midiOutPlayNextPolyEvent这个函数。

异常发生位置处的代码为：

其中的v19和v16的来源：

其中wParam就是该函数的参数，但是根据函数调用情况中得到的参数b2ceeb54查看内存内容，发现全是问号，可能是在执行过程中有修改：

除此之外，如果观察midiOutPlayNextPolyEvent函数的代码，会发现它一直在基于wParam的某个偏移取值，所以现在关键是确定wParam是什么。

重新调试（我之前建立了快照），这次在midiOutPlayNextPolyEvent函数这里设置一个断点：

实验的时候发现第一次中断并不是发生异常的那次调用，第二次才是。看一下esp的内容：

此时还没有进行栈帧的分配，所以wParam的值为27db4f60，看一下这里的内容：

老实讲看不出什么来.所以还是要继续往下单步调试，查看一下数据来源。

但是调试之前，要先对IDA中的代码进行一些简单的分析。

在《漏洞战争》中提到了”导图推算“的分析方法，由于在midiOutPlayNextPolyEvent函数中可以很清晰的看到它在一直在基于wParam的某个偏移取值，并进行一些比较判断和数值运算，而最终我们关注的异常发生位置的变量取值也是在此基础上不断进行数值传递得到的。因此可以根据IDA中得到的代码，整理出该取值的数值传递流程，然后在调试器中设置多个断点，将各相关变量的取值变化打印出来。

如果不参考书中的方法，我应该也能想到去查看伪代码，但是可能不会像书中一样完整的整理出来，而是会选择在逐步调试的过程中进行确定。

对IDA生成的伪代码进行精简，专注于最终异常发生位置代码v21 = *v20;中变量的传递流程，得到：

画出对应的流程图：

再整理出这几个关键变量的赋值位置：

但是有一个问题需要注意，部分指令不能直接在上述位置设置断点，而是应该在下一句指令处设置断点，获得赋值后的数值。

继续做整理：

还是让程序中断在midiOutPlayNextPolyEvent函数的起始位置，设置好断点之后继续执行，每次都会中断在函数开头：

原始输出比较乱，整理成表格之后得到：

首先吸引我注意力的就是V17，很明显这里保存的是状态码，而WParam_3a中保存的是状态码的下一个字节数据。所以说这个函数在循环处理文件中的不同event的信息，在处理到最后一个event，即00 9F B2 73 // 0xB2号音符开始的时候，出现了异常。

除此之外，可以发现：

在第一次函数调用时，函数并不会执行到处理v19和v20的代码处。

从IDA的伪代码也可以看出来，在处理这两个变量之前，程序会进行一次判断：

也就是说，异常发生在函数处理8x或者9x的状态码的时候。

再次回顾，发生异常的数值V20的计算公式是：

根据上面的分析，V16是一个基地址，而偏移地址V19的计算公式是：

其中wParam_3a是音符编号，最高比特位是0，V17是状态码，一定以9开头。

要想实现堆溢出，一定要让V19的值尽可能的大。按照MIDI的格式规范，wParam_3a包含7比特有效数据，最大值为0x7F，但是这里为了实现溢出，选择了0xB2。而为了通过判断条件，V17可变数据只占用四个比特，最大值为0x9F。这里就选择了这个最大值。

再具体看一下0xB2这个值的选取，基地址V16的值是27db6c00，该地址信息：

所以这是一个大小为0x400的堆块，所以偏移只有超过0x400才会发生堆溢出。

当V17取最大值0x9F的时候，((v17 & 0xF) << 7)计算结果为0x780，因此wParam_3a的值至少要到0x80才会发生堆溢出。也就是说对于合法的MIDI文件来说（即最高比特位为0），此处代码不会发生堆溢出。

可以实验一下，把测试用的文件中0xB2修改成0x80，重新打开cve-2012-0003-ie6.htm，同样发生了异常：

之后把这个值修改成0x7F，没有发生异常。

还有一个小问题，我们在调试器里查看这个堆块的大小是0x400，但是这个大小是怎么得到的呢？是硬编码的大小吗？

从上面的输出信息中可以看出这个堆块是在WINMM!mseOpen函数中调用winmmAlloc函数生成的，我们在IDA中找到这个函数，可以看到：

堆块大小确实是硬编码到程序中的，所以一旦偏移超过，就会发生堆溢出。

在分析怎样利用该漏洞时，先确定一下这个漏洞能够做些什么，重新看一下IDA中，异常发生位置之后的代码：

注意到代码*v20 = v23;，这句代码会对溢出位置执行写入操作，所以一定要执行到这里，也就是说：

其中的v21和v22都是读取溢出位置得到的数值。

综上，wParam_3a要是偶数，且溢出位置数值低四位不能全是1，如果满足以上条件，漏洞可以对溢出位置实现增1操作。

wParam_3a不是偶数的条件很好做到，需要注意的就是溢出位置数值低四位的问题。

可以使用IE加载存在漏洞的MIDI文件，而IE的mshtml.dll和MIDI的winmm.dll中，用于分配堆块的堆空间都来自于GetProcessHeap函数。两者使用同一个堆空间，因此有机会在IE中实现该漏洞的利用。

进一步的解释，在mshtml.dll的_DllMainStartup函数（入口点函数）中：

该函数的定义：

Retrieves a handle to the default heap of the calling process

而winmm.dll中的__DllInstanceInit函数中调用了_DllProcessAttach：

转成伪代码：

因此当IE加载MIDI文件的时候，两者使用的是同一个堆空间，即进程的默认堆。

现在已知的是产生漏洞的堆空间大小为0x400，但由于漏洞的存在，导致程序可以对超出该堆空间的内存位置进行增1的操作。如果想要进行漏洞利用，首先应该能够做到分配一个同样大小的堆空间。根据参考资料2，在进行元素的复制的时候，有可能会分配到合适的空间大小。而cve-2012-0003-ie6.html这个文件中的漏洞代码中可以看到：

代码创建了一个包含64个属性的select元素selob，然后创建了一个1000大小的数组clones，并将selob循环赋值到数组clones中，再对偶数位置上的空间进行了释放。这样的一系列操作可以形成空闲块、占用块相互间隔的堆空间结构。但是具体的细节还不清晰。

如果在Windbg中搜索和数组复制相关的函数，可以得到：

如果在该函数上设置断点，程序也会多次中断在这里，说明代码在赋值selob元素的时候，确实调用了这个函数。在IDA中看一下这个函数的代码：

可以看到一个_MemAlloc的函数调用，但是这里只分配了0xC的空间，在往下看，有一个CImplAry::EnsureSize的调用，这个函数也很有意思，里面会进行一个空间分配：

在Windbg中看一下调用到这个函数时的情况：

也就是说这个函数会分配0x42*0x10大小的空间。我看到这个数值的时候就觉得可能会和代码中属性的个数有关，参考资料2中也说EnsureSize会根据属性的个数来分配空间，但是资料中说如果属性有64个的话，那应该分配的就是0x40*0x10的空间，但是我这里看到的却是0x42。目前还不清楚是资料中有一些细节没有提到，还是环境导致的，先继续往下看。

如果按照资料中所说，最后分配了0x400的空间，那么在进行了偶数位置空间的释放之后，每个空闲的0x400大小的堆块后面都会有一个0x400大小的由我们控制的堆块空间，这样一来，漏洞代码申请的0x400大小的空间后面就是我们控制的数据了，接下来需要做的是让增1操作发生的时候，能够引发虚函数指针的泄露，从而控制程序的执行流程。

先来观察一下这个我们控制的0x400大小的堆块数据中是什么内容，因为EnsureSize调用之后，会使用CAttrValue::Copy函数对数据进行复制，在Copy这个函数中，数据的复制操作是这样实现的：

可以看到数据从第一个参数的位置复制到了ecx所指向的位置，所以可以直接检查调用Copy之前，第一个参数所指向的位置：

根据参考资料2，3942ba0处的数据，第二列表示的就是属性的不同类型，其中0x09表示表示object，0x08表示string，这也和selob中对于属性的设置相符：

注意到object类型和string类型代表的数值之间相差了1，如果利用漏洞造成的增1操作，就有可能把原本的string类型修改为object类型，从而导致原本的字符串内容当作虚表指针被引用，这也是这次漏洞利用的原理。

再检查一下目标地址的情况：

可以看到确实是在EnsureSize中分配的空间，但是大小有0x480，和一开始期待的0x400并不相同。

在3.3小节的最后，我们已经确定了发生异常的0x400空间的分配位置是位于76B5CDE9的_winmmAlloc函数调用。而在本小节，也确定了漏洞利用时的分配空间操作是在EnsureSize函数中完成的，可以根据函数调用之后ecx的值确认分配的空间位置，这里选择位于.text:7DDAE80D 8B 48 04 mov ecx, [eax+4]之后的操作。

在这两个位置下断点，我们可以确定发生异常时的空间分配是否真的占用了漏洞利用代码中释放的空间：

如果这时候直接执行查看输出结果，会发现winmmAlloc得到的空间地址和Clone函数中得到的空间地址没有相同的，这是因为开启了页表，需要关闭页表，然后在原本发生异常的位置76b5d224设置一个断点，然后重新调试。

截取部分输出内容：

最后中断在原本异常发生位置：

第一次中断位置在0020ca91，这个值距离分配的空间起点为0x251，和3.2小节中得到的v19的第一次偏移量相同；第二次中断在0020cc59，距离分配的空间起点为419，确实比空间大小0x400多了0x19个字节。

唯一的问题就在于，不知道是什么原因，EnsureSize函数分配的空间大小不是0x400，而是0x480

现在先不去管为什么分配的空间多了，我直接修改了测试文件，删除了最后的两个属性w62和w63，重新调试，断点不变，得到的输出结果截取：

可以看到这次中断在了001e86a9位置，距离winmmAlloc分配的空间0x419，而且也和Clone分配的空间001e8698距离为0x11（因为每个堆块还是8字节的头部），但是读取的字节是0x09，而不是我们预期的0x08。观察一下001e8698空间：

第一行的内容貌似并不是w0 object属性，还是绕过原因不谈，再次删掉w0属性，同时恢复一个之前删除的属性w62，再次调试，保持断点不变：

这次读取到的字节是0x08，如果继续往下单步调试，会发现这里的数值确实修改成了0x09。

根据参考资料2，被修改成object的string元素之后会用来触发CAttrValue::GetIntoVariant()函数的调用，也就是漏洞利用代码中的clones[k].w1('come on!');语句，注意这是一个函数调用。直接在IDA中查看一下这个函数的代码：

可以看到，如果类型是object的话，最后会有一个函数调用：(*(void (__stdcall **)(_DWORD))(*(_DWORD *)v4 + 4))(*((_DWORD *)this + 3));

我们直接在这个函数调用之前设置一个断点，然后继续执行，中断在这个位置：

注意这里从eax指向的位置取出的值，就是漏洞利用代码中selob.w1 = unescape("%u1be4%u0c0c")中的值，继续单步到达函数调用处：

跳转的地址正是0x0C0C0C0C。

因为我不确定原本的漏洞利用代码中shellcode的作用，执行之后也没看到效果，所以我把原本的shellcode换成了弹计算器的代码，最后成功弹出了计算器：

通过对原始漏洞利用代码的调试，以及参考资料2中的内容，确定了漏洞利用的原理，并且对原始代码进行修改，成功进行了漏洞利用。现在唯一的问题就在于，为什么要进行这样的修改。

对于漏洞利用代码的修改主要集中在select元素selob的属性个数以及string属性的位置上。按照参考资料2的说法，EnsureSize函数分配的空间大小应该是0x10*属性个数，但是在我实验的过程中，发现设置64个属性后分配的空间大小为0x480。我们来详细看一下EnsureSize函数，最后分配空间的代码是v13 = _MemAlloc(dwBytes);，追踪一下dwBytes这个变量：

不知道出于什么原因，64个属性值最后传入EnsureSize函数的数值是0x42，再加上对齐操作，导致0x42变成了0x48，结果分配了0x480空间。同样，由于有这个对齐操作，即使设置的不是64个属性，最终也能分配到0x400的空间。

还有一个问题就是在查看clones数组中每一个复制之后得到的数据时，发现第一行数据并不是selob的第一个属性内容，因此我在修改漏洞利用代码时，删除了属性w0，让string属性w1成为第一个属性（或者也可以修改MIDI文件）。

回到程序刚刚调用CAttrArray::Clone函数的快照，取消页表，并删除w62和w63属性，如果在该函数中的EnsureSize调用之后以及Copy调用之后设置断点，在第一次中断之后可以确定程序分配的空间起始地址：

起始地址为ecx寄存器的内容020c0450，之后继续执行，断在第二个断点，此时应该完成了第一个属性的复制，查看一下之前分配的空间内容：

发现第一行内容就是第一个属性的内容，那么为什么在之前调试时会出现问题呢？在020c0450这里设置一个写断点：

程序断在了CImplAry::InsertIndirect函数内，看一下函数调用流程：

也就是说，在Clone函数中，复制完属性信息之后，程序又调用了EnsureHeader函数，并在所有属性信息之前，直接插入了10字节的头部信息，所有属性信息后移一位（10个字节）。

至少现在我知道传入EnsureSize函数中的数值大于0x40的原因了，因为它还要为头部预留空间，可能还有一些其他信息也要预留空间，因此最终预留了0x20的空间。

在参考资料2中也提到了，这个漏洞除了可以实现增1的操作外，也可以实现减1的操作。在发生异常的midiOutPlayNextPolyEvent函数中：

可以看到如果状态码是8x的形式，程序流程就会进入到上面的判断语句，然后执行到减1的操作。

这次漏洞分析中，只要了解了MIDI文件格式，那么一旦确定异常发生位置，在IDA中找到对应函数及其伪代码，通过对伪代码的分析，很容易确定漏洞产生的原理，其中书中介绍的导图推算的方法，画出变量的数值传递流程图，会让整个过程更加清晰。

VUPEN采用的漏洞利用方法十分新颖，具有借鉴意义。利用CImplAry中每个属性占据0x10空间的原理，不断分配和释放同样大小的堆空间，从而控制漏洞函数所分配空间周围的空间数据；利用string属性和object属性之间差值为1的特性，使用该漏洞将string属性变成了object属性，从而暴露出虚函数地址，让程序流程跳转到攻击者控制的数据中。

由于漏洞利用代码本身存在错误（和msf生成的不同），在修正问题的过程中，虽然花费了更多的时间，但是对漏洞利用的手法也了解的更为深刻。

Advanced Exploitation of Internet Explorer Heap Overflow Vulnerabilities (MS12-004)

注：该网址已失效，可以在archive.org中搜索

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！