介紹

在Chromium v8中x64平臺的指令優(yōu)化中發(fā)現(xiàn)了UAF漏洞。成功利用此漏洞可以允許攻擊者在瀏覽器上下文中執(zhí)行任意代碼。

該漏洞是由于v8在優(yōu)化結束之后，指令選擇階段，選擇了錯誤的指令，導致的內存破壞漏洞，成功利用此漏洞，可以達到代碼執(zhí)行的效果。

該漏洞發(fā)生在

https://chromium.googlesource.com/v8/v8/+/71a9fcc950f1b8efb27543961745ab0262cda7c4%5E

之前(含本次提交)，如果想重現(xiàn)此漏洞，可以同步代碼到此次提交之上。

poc:

代碼主要的功能及原理：

1.首先創(chuàng)建一個typed array數(shù)組，大小為0x10000

2.然后判斷a[0]的值是否為非零，然后結果賦值給b

3.然后進行垃圾回收

4.如果b為true，打印字符串boom

運行上面的代碼輸出的結果：

可以看到，訪問違規(guī)的地址就是a的data_ptr: 0x7f71576a0000

代碼首先，調用了runtime函數(shù)gc，然后[r8],0做對比：

漏洞產(chǎn)生的原因

在前兩次運行的時候，v8知道對數(shù)組a的使用只是在步驟2處，后續(xù)并沒有訪問數(shù)組a，所以在優(yōu)化編譯階段，gc把v8的數(shù)組存放的內存給回收了，數(shù)組a的內存被釋放了，但是由于v8在x64平臺上錯誤的生成了指令，導致在4處訪問到了已經(jīng)被回收的頁面，造成了內存訪問異常，也就是在0x7f6e29984162地址處，又一次的訪問已經(jīng)被釋放的數(shù)組a的內存，從而導致crash。

優(yōu)化過程：

因此，在執(zhí)行第4步時，它正在訪問已回收的同一位置，導致地址0x7f6e29984162的內存訪問異常，其中再次訪問已釋放的數(shù)組a的內存，導致內存損壞和崩潰。

補丁對比

修補代碼刪除了CanCoverForCompareZero函數(shù)，恢復了CanCover的使用 CanCoverForCompareZero的作用是用來代替在函數(shù)VisitWordCompareZero中canCover。如果canCover返回了false，但是這個節(jié)點是一個比較的節(jié)點，就不需要其他的任何寄存器，可以被user節(jié)點給cover住。

一般情況下這個沒有問題，但是問題恰恰出現(xiàn)在當訪問內存的時候，此時生成的代碼會直接去比較內存，而不是先獲取比較結果，在去進行比較，但是當在第二次訪問內存的時候，調用gc，就會造成UAF。這時候會調用這個函數(shù)，用來訪問a的數(shù)組buffer，如下圖所示：

在這里生成轉化為具體的指令

因為易受攻擊的代碼采用CanCoverForCompareZero為true的路徑，從而生成不同的指令序列（易受攻擊版本VS固定版本）。

指令序列的詳細分析

在分析了Turbofan的優(yōu)化階段后，我們知道這個問題發(fā)生在最后兩個階段：

在計劃階段，節(jié)點信息完全一致，但之后變得不同，我們找到了相關的指令序列。

事實上，相應的js代碼是const b=a[0]！=0；

修補前：

修補之后：

乍一看，它似乎完全相同，但由于漏洞，這里生成的代碼不同（請注意，114的左側，修復前是一個點，修復后是一個圓圈和一個點，這意味著修復前的114行不是直接生成的指令，而是從33個輸入中提取，以生成優(yōu)化的指令序列——指令折疊。

在易受攻擊代碼中，當調用VisitWordCompareZero時，CanCoverForCompareZero將返回true，因為Word32Equal節(jié)點是一個比較類型位置。由于后續(xù)訪問是cmp指令，v8不需要在注冊表中存儲比較結果，但假設后續(xù)訪問（即if（b）語句）可以再次直接訪問數(shù)組a的內存，并最終生成包含更少指令序列的優(yōu)化代碼。

這就是注冊表分配之前發(fā)生的事情：

修復前：

修復前生成的相關指令：

修復后：

修復后生成的相關說明：

生成25行指令序列：

生成26行指令序列：

比較修復前后的2組指令，條件指令的差異與setnzl VS setzl相反，因為修復前的代碼在函數(shù)VisitWordCompareZero中執(zhí)行cont->OverwriteAndNegateIfEqual（kEqual）。

以下顯示了修復漏洞后的TurboFan程序集指令（注意生成的代碼指令序列比修復之前更長）：

在圖5中，我們可以看到比較結果首先放在堆棧[rbp-0x28]上，然后將[rbp-0x28]與0進行比較，在這種情況下，它將不會訪問gc中的內存，因此不會出現(xiàn)UAF問題。

修補代碼對比

https://chromium.googlesource.com/v8/v8/+/71a9fcc950f1b8efb27543961745ab0262cda7c4%5E%21/#F0

對比修補的代碼，我們看到，恢復了canCover函數(shù)，刪除了CanCoverForCompareZero，這樣就不會將對比的節(jié)點這種情況來進去到這個switch case里，也就

不會產(chǎn)生錯誤的指令生成。

利用思路

本漏洞通過堆噴的方式，覆蓋a的數(shù)組內存，然后轉化為類型混淆漏洞，之后再利用類型混淆，來實現(xiàn)讀寫的能力，最后達到RCE的效果，感興趣的話可以自行嘗試構造。

關于作者

Weibo Wang（Nolan）是一名知名安全研究員，目前在總部位于新加坡的網(wǎng)絡安全公司Numen Cyber Technology工作。他在著名的區(qū)塊鏈項目上發(fā)現(xiàn)了許多高危漏洞，如ETH、EOS、Ripple、TRON以及蘋果、微軟、谷歌等的熱門產(chǎn)品。

[超站]友情鏈接：

四季很好，只要有你，文娛排行榜：https://www.yaopaiming.com/
關注數(shù)據(jù)與安全，洞悉企業(yè)級服務市場：https://www.ijiandao.com/