聲明：該文章來自（Numen Cyber Labs）版權(quán)由原作者所有，K2OS渲染引擎提供網(wǎng)頁加速服務(wù)。

介紹

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

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

該漏洞發(fā)生在

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

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

poc:

代碼主要的功能及原理：

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

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

3.然后進(jìn)行垃圾回收

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

運(yùn)行上面的代碼輸出的結(jié)果：

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

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

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

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

優(yōu)化過程：

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

補(bǔ)丁對比

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

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

在這里生成轉(zhuǎn)化為具體的指令

因?yàn)橐资芄舻拇a采用CanCoverForCompareZero為true的路徑，從而生成不同的指令序列（易受攻擊版本VS固定版本）。

指令序列的詳細(xì)分析

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

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

事實(shí)上，相應(yīng)的js代碼是const b=a[0]！=0；

修補(bǔ)前：

修補(bǔ)之后：

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

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

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

修復(fù)前：

修復(fù)前生成的相關(guān)指令：

修復(fù)后：

修復(fù)后生成的相關(guān)說明：

生成25行指令序列：

生成26行指令序列：

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

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

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

修補(bǔ)代碼對比

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

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

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

利用思路

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

關(guān)于作者

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

[超站]友情鏈接：

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