office CVE-2017-11882 exp构造
尝试了一下CVE-2017-11882的手动构造，过程有些小坑，遂记录一下。
如下图所示通过传入对象的方式向docx中插入一个equation的对象。
选择的对象为微软公式microsoft 3.0。
之后会弹出对应的对象工具，即导致该漏洞的核心组件equation.exe，在公式中写入一串字符，注意一定要写（后面会说到），保存退出。
使用解压工具解压，如下所示
进入word/embeddings这个目录，该目录下保存着对应的ole对象。
将该bin拖到010 edit中，如下所示，其中比较重要的是900-9f0这一段区间，所有的exp构造都在该段数据中实现，大致分为三个部分
- eqnolefilehdr
- mtef header
- size
- 之后的部分可供插入mtef byte stream，由一个个records组成，导致漏洞的records为对应的fonts类型records
因此直接往之后插入font即可，font record如下所示为其中蓝色和褐色部分，其中蓝色部分为固定的tag+typeface+style，褐色为font_name（也即是导致溢出的部分）。
如下所示为漏洞部分代码，其中a1即为上图构造的font_name，由于没有做长度检测，导致溢出。
通过解压工具将该修改过的bin文件替换原docx中的bin文件，注意不要解压后替换再打包，这样会报错。
如下所示，由于没有相关的自动执行的功能（可以通过rtf实现，这里不再赘述），因此需要点击该equation才能触发漏洞程序。
点击后发现并不会崩溃，挂上调试器可以看到如下所示，溢出时准备的string被截断了24位的长度（缓冲区为0x2c），从而导致溢出无法发生。
这是因为输入的公式中的字符长度问题（目前看来该字符的长度决定了可以往溢出地址拷贝的长度，也就是说拷贝的字符并不由bin中font_name的长度决定，如之前字符为123456,长度6*4=24，即为上面的拷贝长度），同时也要注意实际上最短的长度也是有限制的，即最少保证24长度的拷贝，哪怕你将公式中的字符改为12（长度为2），其拷贝长度也是24，而不是8，通过对比可以知道字符长度不同导致该bin文件中一下三处差异，第一处为这个0x45,0x45为对应的font_name的长度，第二处为61，效果目前未知。
及第三处的80，即字符不同长度影响的生成的两个docx中oleObject1.bin主要会有这三处的不同，从而导致wwlib在解析这个docx时拷贝的font_name长度不一致，具体细节感兴趣的童鞋可以调试一下，其实只要记住控制插入公式的字符长度大于缓冲区的0x2c即可。
如下控制字符为123456789abcdef。
因此增加该字符的长度后，如下所示123456789abcdef，15*4=60，即现在可往缓冲区拷贝的长度为60，可以看到此时esi指向的字符长度正是60，目标地址中红框为对应的返回地址。
此时运行崩溃。
修改对应的bin，使返回地址为对应的Winexec地址即可，注意以00结尾
此时运行
Strcpy之后返回地址被覆盖为Winexc。
可以看到由于该漏洞函数的特性（第一个参数时溢出字符，第二个参数为null）正好符合Winexe的调用规则，因此只要将返回地址覆盖为Winexec的地址即可导致代码执行。
执行后通过Winexec启动计算器。
效果如下:
该文章http://bobao.360.cn/learning/detail/4753.html
中作者构造是提到了漏洞函数之前有两个坑，实际上应该是其一开始的equation中的字符过长导致，如果只是123456789abcdef这么长，我们往溢出地址拷贝的长度就只有60，可完美实现exp，同时不触发其余的函数溢出。
如下所示构造一个公式中字符串超长的docx，运行，此时可以看到该文章中对应的溢出。
相关参考：http://bobao.360.cn/learning/detail/4753.html
转载请注明出处
