同样是Chakra的漏洞，17年之前的应该都可以触发
漏洞POC参考自holynop师傅的文章

执行POC发现异常发生在如下位置

其中object的值为0x0000000600000005，导致内存访问异常
向上追溯发现是把array中的值解释为了指针

↓

↓

↓

其中0x0000000600000005的值其实就是我们POC中的intarr，因为intarr的类型是JavascriptNativeIntArray，因此它内存布局是这样的。

可以见得正是把JavascriptNativeIntArray中的5、6元素解释成指针才导致的crash，强制解释的操作如下

我们知道这个漏洞是因为Proxy对象劫持Prototype导致的混淆，那么不使用Proxy劫持Prototype而是直接设置Prototype可以触发吗？

调试发现是不行的，此时intarr的内存会变成如下情况

并且由Tyoe Object可知此时intarr已经被从JavascriptNativeIntArray转化为JavascriptArray

并且根据前面的代码可以知道,此时并不会把TaggedInt混淆为指针（或者说对JavascriptArray做了正确处理）

在此我们分析一下漏洞函数，漏洞产生的函数如下

这个函数由JavascriptArray::ReverseHelper调用，ReverseHelper对应于array.prototype.reverse函数

reverse() 方法将数组中元素的位置颠倒。
第一个数组元素成为最后一个数组元素，最后一个数组元素成为第一个。

var myArray = ['one', 'two', 'three'];
myArray.reverse();
console.log(myArray) // ['three', 'two', 'one']

在JavascriptArray::ReverseHelper中会执行IsFillFromPrototypes判断是否需要进行FillFromPrototypes的操作

其条件之一就是判断this->length == this->head->length，这也是POC中要添加arr.length = 24才会触发的原因。执行之后this->length会变成我们设置的值24而this->head->length仍为原长度不变，因此才会调用FillFromPrototypes触发漏洞。

之后在FillFromPrototypes中会依次获取arr的prototype对象直到prototype对象类型为TypeIds_Null为止

调用的子函数JavascriptArray::ForEachOwnMissingArrayIndexOfObject中会采取以下操作

arr是prototype数组对象，baseArray是初始的array(即脚本中arr)，这里的意思是当prototype数组中存在并且原数组中不存在时就进行设置，POC中的

也因而得以解释，intarr必须要比arr要长才可以触发漏洞。并且这里对于fn调用也是最终导致了以Var方式访问JavascriptNativeIntArray

关于利用的更多细节可以查看holynop的原文
202K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3u0D9L8$3N6K6i4K6u0W2x3K6j5H3i4K6u0W2j5$3&6Q4x3V1j5K6y4U0m8K6j5h3k6W2i4K6u0r3x3U0l9I4y4W2)9J5c8U0p5I4i4K6u0r3x3U0W2Q4x3V1k6@1K9s2u0W2k6g2)9J5k6s2u0G2j5h3c8K6i4K6u0V1L8r3g2S2k6q4)9J5k6s2c8G2i4K6u0V1M7X3!0E0k6g2)9J5c8R3`.`.
此外这个漏洞也是今年Vulcan在HITB的议题《The Secret of ChakraCore:10 Ways to Go Beyond the Edge》的一部分

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课