-
-
[讨论]关于google前几天爆出的 chrome 0day 和简单poc
-
发表于: 2021-4-15 20:23
-
*第一部分：
#
https://mp.weixin.qq.com/s/dZl_Urk8cOJ1Qbe16HBFGQ
POC地址
https://github.com/r4j0x00/exploits/tree/master/chrome-0day
最开始看到是这个漏洞是从某个公众号
点进去这个链接
看了一圈
这边的公告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
https://www.anquanke.com/post/id/229482
尝试这里的方法，最后不知道为什么用%OptimizeFunctionOnNextCall没有触发优化
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | const _arr = new Uint32Array([2**31]);function foo() { var x = 1; x = (_arr[0] ^ 0) + 1; x = Math.abs(x); x -= 2147483647; x = Math.max(x, 0); x -= 1; if(x==-1) x = 0; var arr = new Array(x); arr.shift(); var cor = [1.1, 1.2, 1.3]; return [arr, cor];}for(i=0;i<0x4000;i++){ foo();}var x=foo();var arr1=x[0];if(arr1.length==-1){ %SystemBreak();}var x = foo(); |
最后只能用这种丑陋的方法，从外面插进去，总算可以看看优化后发生什么事了。
2021/5/21 尴尬的发现补丁和漏洞不是同一个
[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)
苏啊树
