前段时间趋势披露了VBS引擎的在野0day CVE-2018-8373，当时中心第一时间披露了该次攻击和Darkhotel的关联，上周花了段时间将该漏洞的exp构造出来，如下所示，目前来看UAF占位上不是太稳定，后续会继续改进，构造exp的时候遇到一些坑，遂找时间记录一下。
利用思路上趋势的文章中其实已经介绍得很清楚，在Default Property中通过一个二维数组array1对释放的array（2）内存进行占位，并返回一个大的0x0FFFFFFF值，当cls.array(2) = cls赋值时，该0x0FFFFFFF会写入到array（2），由于该array（2）的内存空间之前巧妙的被二维数组array1占据，写入到0x0FFFFFFF正好将该二维数组的其中一维长度被设置为0x0FFFFFFF。
通过该array1（0x0FFFFFFF，2）创建一个超长的fakearray，从而实现全局内存读写（期间需要在array1中搜索两个特殊的index，可以使用银雁冰同学之前提供的方法，即暴力的type类型搜索）。
这个地方遇到的坑就是构造的时候最好不要在打了CVE-2018-8174的机器上测试，如下所示是我们正常构造的array1二维数组，其中红框对应的具体的两个维数（红框），我们的目标就是通过cls.array(2) = cls修改这两维。
返回的数据如下所示，这是一个int类型变量的内存结构，其数值为0x0FFFFFFF，可以看到绿色部分不为0（而是改为了C0），第一个红框中的8个字节的高字节也不为0（同样也是C0），注意这样的内存结构是固定的。
这就导致之后cls.array(2) = cls返回二维数组被修改如下，但是这样的二维数组的内存结构是有问题的，此时你直接操作该二维数组将导致报错（数组越界，超过0x0FFFFFFF）。
如下所示可以看到一个标准利用时被修改的array1的内存结构应该如下（该图来自于趋势科技的原文），通过后来的调试发现，8174之前的补丁0x0FFFFFF对应的内存结构就是下图红框所示（虽然绿框中0部分有时也不为0，但是其整体的值不会大于0x0FFFFFF）。
但是打过8174补丁之后，其中绿色的部分会被填充上数据（固定填充），从而导致之后难以利用。
其主要原因在于CScriptRuntime对象的Local Variables在补丁之后会初始化为C0的形式。
而变量的初始化时直接在这块内存上进行的，如下可知对int类型的变量只是简单的将3,4字节赋值为0003（int的type类型），8-c赋值对int的实际值，其余位置默认为内存的初始化值C0。
因此这里我挺好奇当时趋势抓获的样本中是否有相应的技巧将0x0FFFFFF变量的内存进行规范化，还是说他们当时测试的时候是在没有打8174补丁的机器上进行，如果是第二点的话，该漏洞的利用似乎在打了8174补丁上的机器上是无法利用的（如果不能很好解决变量初始化时的C0问题）。
转载请注明出处
参考