能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
[原创] CVE-2024-0517 漏洞分析
XiaozaYa
但我还是感觉是一个 UAF,,,,[em_5]
栈上的指针指向前后因为垃圾回收前后指向的值应该发生了变化,这个情况在MaglevIR层面上好像看不到,垃圾回收后在这个IR指令层面从栈拿出来后那个地址已经指向了垃圾回收后的地址,但是问题是在垃圾回收之后,他前面的对象已经被回收了,这时正确的处理应该是使用offset为0的地址索引,但是有漏洞的版本使用offset+12,越界写到了其他对象,造成了崩溃。 就是你截图的 31/32FoldAllocation[+12]这个指令,是有问题的。 所以利用时候应该是越界写相邻的数组大小这种思路,而不是UAF的利用方法,不是依靠占位,我估计这就是你一直没有成功利用的原因。。。
最后于 2024-4-22 13:37
被苏啊树编辑
,原因:
|
能力值:
( LV9,RANK:250 )
|
-
-
[原创] CVE-2024-0517 漏洞分析
Google Chrome V8 CVE-2024-0517 Out-of-Bounds Write Code Execution这标题意思是越界写,不是UAF,这个如果没弄清的话估计用不出来。 我看了这篇文章,还没有自己调试,我的理解是,因为优化过程中没考虑到垃圾回收的情况,所以那个指针Offset+12没有清零。 但是发生垃圾回收到了新堆块以后,Offset+12之前的对象+4,+8偏移的对象被垃圾回收清除,并不会转移到新的堆块,这时再用新堆块+Offset12索引的话,就会越界写破坏到了别的对象。 如果我的理解是正确的,这个漏洞利用不需要占据释放后的内存,只需要知道垃圾回收后的内存布局,然后越界修改就行了。
最后于 2024-4-22 10:42
被苏啊树编辑
,原因:
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|
能力值:
( LV9,RANK:250 )
|
-
-
|