*第一部分：

#
eceK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6E0M7q4)9J5k6i4N6W2K9i4S2A6L8W2)9J5k6i4q4I4i4K6u0W2j5$3!0E0i4K6u0r3M7#2)9J5c8X3c8K9L8q4)9#2k6W2g2J5K9K6S2U0e0@1Z5I4f1h3u0W2x3e0k6t1b7V1k6s2f1b7`.`.
POC地址
b96K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6J5y4r3Z5H3P5o6l9H3i4K6u0r3k6i4S2H3L8r3!0A6N6s2y4Q4x3V1k6@1M7X3g2W2i4K6u0r3L8h3q4K6N6r3g2J5i4K6u0r3j5$3S2J5L8$3#2W2i4K6u0V1x3r3c8S2P5b7`.`.
最开始看到是这个漏洞是从某个公众号

点进去这个链接

看了一圈
这边的公告v8漏洞就只有个Tencent Security 报告的V8的UAF，而这边给出的POC 是：
foo(){…}
for(var i=0;i<0x3000;++i)
foo(true);
这样子的，显然这POC写的是v8的JIT的漏洞，公告上没有一个符合的。难道预示着这个v8的 UAF漏洞没有纰漏，后面还有我们值得期待的惊喜？

第二部分：POC和补丁


/分析结果就是补丁 在output_type.Is(Unsigned32) 判断的时候，加入了需要判断满足use_info.type_check() == TypeCheckKind::kNone 这个条件。
如果类型为Unsigned32的时候，对其再做了类型判断，再进入流程op = machine()->TruncateInt64ToInt32();
op = machine()->TruncateInt64ToInt32();这个流程根据字面上的意思是转化为Int64到Int32的opcode。
换句话来说是优化时处理Unsigned32类型(32位无符号)生成的opcode的过程出现了问题：
最后打印v8处理过程，触发函数：
这一段代码在没有优化的时候执行是这样的，如果执行优化的话：

触发以后：

猜测其运算过程（纯脑洞）
都是无符号数Int64
x = (_arr[0] ^ 0) + 1;
x = Math.abs(x);
x -= 2147483647;=>推测这个过程发生了：
补码 01111111111111111111111111111111 + 10000000000000000000000000000001（这里都是处理为Int32有符号）
= 100000000000000000000000000000000/这边可能溢出符号没正确处理或则放入Int64之中/
然后结果再加（这边-1处理为补码）1111111111111111111111111111111(x-=1，这边的还是Int32)
=101111111111111111111111111111111/这边可能溢出符号没正确处理或则放入Int64之中/
根据结果猜测是这可能时出现了错误截断变为1111111111111111111111111111111
这边的截断把他解释为有无符号数
也就是最后是等于4294967295（1111111111111111111111111111111）这个的来由
但是再Ubuntu上的v8插入console.log()的话会发生OOM崩溃，暂时还不知道有什么办法验证验证，而且还发现自己的基础知识好像很薄弱，很迷茫。
*2021.4.16
3d5K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2S2L8Y4q4#2j5h3&6C8k6g2)9J5k6h3y4G2L8g2)9J5c8Y4m8G2M7%4c8Q4x3V1k6A6k6q4)9J5c8U0t1J5z5e0b7^5x3R3`.`.
尝试这里的方法，最后不知道为什么用%OptimizeFunctionOnNextCall没有触发优化

最后只能用这种丑陋的方法，从外面插进去，总算可以看看优化后发生什么事了。
2021/5/21 尴尬的发现补丁和漏洞不是同一个

[注意]看雪招聘，专注安全领域的专业人才平台！