CVE-2020-9802：Incorrect CSE for ArithNegate 导致的越界访问

发布于2024年5月9日2025年7月19日作者:cve-20

CVE-2020-9802：Incorrect CSE for ArithNegate 导致的越界访问

XiaozaYa 看雪学苑 2024-05-08 18:02

最近尝试阅读DFG jit
相关源码，但是无从下手，网上资料甚少并且代码量巨大，所以笔者对应JSC
的学习路线还是从相关CVE
中去学习一些有关JSC
的基础知识，这里逐渐积累，等到合适的时候，再去尝试阅读源码，该漏洞比较老了，但是复现漏洞不是目的，重要的是学习一些知识。复现这个漏洞主要是学习下CSE
优化这个知识点，其实挺简单的。CSE
即公共子表达式消除，其主要的操作就是将多个相同的表达式替换成一个变量，这个变量存储着计算该表达式后所得到的值，考虑如下代码：

上述代码可能会被优化成如下代码：

这样就避免了b * c
表达式的重复运算，但是并非所有情况下都可以进行CSE
优化，考虑如下代码：

这里我们就不可以将其优化为如下代码：

理由很简单，f()
存在side effect
，即obj
对象可能在f()
中被修改，比如如下代码：

如果这里将其优化，则导致a = b = 1
从而出现错误，那么JIT
编译器是如果判断公共子表达式是否可以进行消除呢？对于JSC
而言，其会在DFG
阶段收集相关信息，然后在FTL
阶段利用收集的信息判断是否进行CSE
优化，收集信息阶段主要在DFGClobberize
函数中进行，这个我们后面再看。

手动引入patch
然后编译即可：

可以看到上述补丁主要打在了clobberize
函数中，通过前面的铺垫，可以知道这里应该就是DFG
收集相关信息时出现错误，从而导致在FTL
阶段发生错误的优化，定位到源码：

这里代码很长，所以只需要定位关键代码即可

这里可以看到patch
代码仅仅给PureValue
函数添加了一个参数node->arithMode()
，这里根据p0
的文章可以知道：

The def() of the PureValue here expresses that the computation does not rely on any context and thus that it will always yield the same result when given the same inputs. However, note that the PureValue is parameterized by the ArithMode of the operation, which specifies whether the operation should handle (e.g. by bailing out to the interpreter) integer overflows or not. The parameterization in this case prevents two ArithMul operations with different handling of integer overflows from being substituted for each other. An operation that handles overflows is also commonly referred to as a “checked” operation, and an “unchecked” operation is one that does not detect or handle overflows.

加上node->arithMode()
表示说具体不同整数溢出处理方式的操作不能替换，然后操作根据是否检查溢出分为checked operation
和unchecked operation。
所以这里的漏洞就比较明显了，def(PureValue(node));
表示能否进行替换只与输入的值有关，对于ArithNegate
而言，其是unchecked operation
，当value = TYPE_MIN
时会发生溢出，即-TYPE_MIN = TYPE_MIN
；对于ArithAbs
而言，其是checked operation
，当value = TYPE_MIN
时，其会进行符合扩展去处理溢出情况，所以abs(TYPE_MIN) = |TYPE_MIN|
；而ArithNegate
与ArithAbs
操作是可以产生相同的效果的，比如-(-1) = abs(-1)
，所以对于如下代码是可以进行优化的：

上面优化看似不存在问题，但是当发生溢出时就会出现问题，比如如下代码：

可以看到这里优化CSE
优化导致b
的值发生错误，其本来应该为|TYPE_MIN|
，但是编译器却认为其为TYPE_MIN
，其实这就是这个漏洞的全部原理了。poc
如下：

可以看到这里输出的b = -2147483648 = -0x80000000
，来简单看看字节码。

首先看看f
产生的字节码：

[11] negate
表示的就是-n
，[41] call
表示的就是Math.abs(n)
，来看下在DFG
后的字节码。

可以看到[11] negate
被展开为如下IR
：

[41] call
被展开为如下IR
：

即：

可以看到ArithNegate
是unchecked
的，而ArithAbs
是CheckOverflow
的，即ArithNegate
与ArithAbs
具有不同的溢出处理机制。接下来看看FTL
阶段：

即：

可以看到这里ArithAbs
被优化掉了，即编译器认为ArithNegate
与ArithAbs
在操作数是负数时是等效的，但是上面说了这两个操作对于溢出的处理情况是不同的，所以这两个操作并不是完全等效的。

接下来就该考虑如何去进行利用了，总结一下上面漏洞的效果：

◆一个运行时不一致的TYPE_MIN

后面的利用有点类似于V8
中消除CheckBounds
节点，即利用编译器检查时与运行时不一致漏洞去消除边界检查，考虑如下代码：

可以看到这里【1】
处首先保证了n < arr.length
，【2】
处为减二，所以n < arr.length-2 < arr.length
，【3】
处保证了n >= 0
，所以编译器最后会推断arr[n]
中的n
的范围在[0, arr.length)
之间，所以其肯定不会发生越界，所以其会进行消除边界检查优化。来看下trigger
函数的字节码：

这里主要关注get_by_val
字节码，来看看DFG
阶段：

这里我们主要关注下GetButterfly
和GetByVal
：

从汇编代码可以看到在DFG
阶段并没有消除数组的边界检查，其还是会检查n
是否越界，所以我们再来看下FTL
阶段：

这里的GetByVal
节点与DFG
阶段的似乎没啥不同，所以还是得看汇编代码，但是这里json
似乎没有FTL
阶段的汇编代码，所以只能动态调试了，这里调试可以知道：

rcx = butterfly; rax = n
，所以这里是直接进行读取butterfly[n]
，并没有对n
进行检查，因为编译器推断此时n
是在数组范围内的。那么回到原漏洞利用中，我们该如何利用漏洞去消除边界检查呢？其实关键就是编译器推断时与实际运行时的值不相同，考虑如下poc
：

poc
的原理我注释已经写的很清楚了，就不多说了，最后输出如下：

可以看到这里成功完成越界读，越界写简单修改下代码为arr[b] = val
即可，poc
的一些构造细节可以参考p0
的文章，其poc
写的更加好，解析的也很详细。有了越界地址读写后面其实就比较简单，我们可以利用该漏洞越界写修改相邻数组的butterfly
的 “容量和长度”，这样就有了一个越界数组，后面就是构造addressOf/fakeObject
原语，然后套模板就行了，就不多说了。

exploit
如下：

效果如下：

通过复现该漏洞，笔者对CSE
优化有了一个大致的了解，并且对一些优化的细节有了更加深刻的理解。然后比较重要的是学到了在JSC
中如何消除边界检查从而完成越界读写。然后在参考文章中，作者写了他是如何发现这个漏洞的，这个漏洞并不是fuzz
出来的，作者也说明了该类漏洞fuzz
的困难性，而作者发现这个漏洞的原因是因为作者在审计代码时发现有的操作没有设置arithMode
，而有的操作却设置了arithMode
，所以作者就想为什么有的操作需要设置arithMode
，而有的操作却不需要设置arithMode
，于是作者就搜索相关没有设置arithMode
的操作，从而发现了该漏洞。从作者发现该漏洞的历程中，也让我反思自己，自己在看代码时完全没有思考过为什么，其实还是自己不善于思考，这也许就是我与大佬的差距吧。