本環(huán)境是基于"火天網(wǎng)演攻防演訓(xùn)靶場(chǎng)"進(jìn)行搭建，火天系列產(chǎn)品提供模擬器級(jí)別的網(wǎng)絡(luò)環(huán)境構(gòu)建系統(tǒng)，可以靈活的對(duì)目標(biāo)網(wǎng)絡(luò)進(jìn)行設(shè)計(jì)和配置，并且可以快速進(jìn)行場(chǎng)景搭建和復(fù)現(xiàn)工作，產(chǎn)品也進(jìn)行了車聯(lián)網(wǎng)設(shè)備對(duì)接，為車聯(lián)網(wǎng)安全訓(xùn)練環(huán)境構(gòu)建提供基礎(chǔ)資源支持

背景

近日，國(guó)內(nèi)多家安全實(shí)驗(yàn)室檢測(cè)到了針對(duì)于智能網(wǎng)聯(lián)汽車中使用都開源項(xiàng)目busybox漏洞，國(guó)外在2022年5月份報(bào)告了此漏洞，目前已經(jīng)發(fā)布的CVE信息如下，信息中指出Busybox1.35-x版本中，awk應(yīng)用由于use after free導(dǎo)致拒絕服務(wù)漏洞或可能獲取代碼執(zhí)行權(quán)限。

漏洞原理

根據(jù)CVE發(fā)布信息公告來看，該漏洞屬于堆溢出漏洞，具體漏洞類型為use after free。簡(jiǎn)單來說，use after free漏洞的形成過程如下，如果我們申請(qǐng)一塊內(nèi)存然后釋放后，此時(shí)重新申請(qǐng)一塊相同大小的內(nèi)存，操作系統(tǒng)為了內(nèi)存空間的管理方便，會(huì)將上一次釋放掉的內(nèi)存重新分配給我們。此時(shí)上一個(gè)申請(qǐng)的指針沒有被清空，而且重新給內(nèi)存賦值的話，就會(huì)影響第二次申請(qǐng)內(nèi)存中的內(nèi)容。use after free的本質(zhì)為倆個(gè)指針同時(shí)指向同一塊內(nèi)存，而當(dāng)一個(gè)chunk被free后，其中該chunk中的數(shù)據(jù)具有部分結(jié)構(gòu)的控制作用，使用另一個(gè)指針修改控制結(jié)構(gòu)的數(shù)據(jù)，程序控制流就會(huì)被改變。

示例如下，在下圖源碼中，我們使用指針chunk1指向了malloc分配了0x10字節(jié)的內(nèi)存，隨后在內(nèi)存中拷貝"test1"字符串到內(nèi)存中，此時(shí)打印出來的chunk1地址為0x8c71e260，里面的內(nèi)容為test1。隨后我們釋放掉chunk1，此時(shí)使用chunk2指針指向malloc重新分配的0x10字節(jié)，然后在chunk2內(nèi)存中寫入"test2"字符串，打印出來chunk2的地址也是0x8c71e260。這時(shí)如果我們向chunk1指針指向的內(nèi)存中寫入"test3"字符串，打印chunk2里面的內(nèi)容，我們就會(huì)發(fā)現(xiàn)明明沒有修改chunk2的內(nèi)容，但是打印時(shí)chunk2里面的內(nèi)容卻變了。

知道了漏洞的大概類型后，我們便可以進(jìn)行簡(jiǎn)單分析。首先在busybox官網(wǎng)(https://busybox.net/downloads/)中，下載1.35.0版本和最新的1.36.0版本。根據(jù)CVE發(fā)布信息我們得知是awk應(yīng)用程序存在漏洞，所以我們直接使用vimdiff比較倆個(gè)版本的awk.c文件。在vimdiff的比較中，我們發(fā)現(xiàn)在evaluate函數(shù)中的case XC(OC_MOVE)中進(jìn)行了補(bǔ)丁更改。

打開1.35.0版本awk.c文件中未經(jīng)patch處的對(duì)應(yīng)代碼塊，該代碼塊位于evaluate函數(shù)中，在該case分支下，出現(xiàn)了CVE公告中提到的漏洞函數(shù)copyvar。由于此時(shí)我們對(duì)整個(gè)程序的架構(gòu)和執(zhí)行流程還不太清楚。我們先簡(jiǎn)單跟一下可能具有漏洞的具體情況，堆溢出的漏洞一般都發(fā)生在*alloc或free函數(shù)附近。use after free漏洞一般在free函數(shù)居多，我們接下來跟流程重點(diǎn)關(guān)注一下free函數(shù)。

進(jìn)入查看發(fā)現(xiàn)clrvar對(duì)第一個(gè)參數(shù)進(jìn)行操作，隨后使用handle_special函數(shù)對(duì)dest進(jìn)行處理。進(jìn)入查看發(fā)現(xiàn)clrvar函數(shù)調(diào)用free函數(shù)對(duì)內(nèi)存進(jìn)行了釋放。

上面的倆個(gè)函數(shù)都用到了var結(jié)構(gòu)體，結(jié)構(gòu)體定義如下：

接下來返回awk_main函數(shù)簡(jiǎn)單觀察一下執(zhí)行流程。發(fā)現(xiàn)程序首先進(jìn)行一系列設(shè)置，指定了標(biāo)準(zhǔn)輸入輸出，隨后使用awk_getline獲取用戶輸入，并循環(huán)使用evaluate函數(shù)進(jìn)行處理。

在evaluate函數(shù)中，首先調(diào)用nvalloc分配了2個(gè)var大小的堆內(nèi)存。然后將該指針命名為了TMPVAR0。隨后根據(jù)傳入的op結(jié)構(gòu)體信息循環(huán)處理。在循環(huán)處理中又使用switch case分支處理，在XC(OC_MOVE)中調(diào)用了我們分析的copyvar函數(shù)。

根據(jù)前面的流程分析和patch后的代碼判斷，如果我們輸入數(shù)據(jù)可以控制L.v的指針指向tmpvars(TMPVAR0)，那么這時(shí)用戶修改的指針和系統(tǒng)自動(dòng)分配的tmpvars都指向同一塊內(nèi)存，而在case XC(OC_MOVE)中，如果當(dāng)其中一個(gè)指針指向的chunk被釋放，而另一個(gè)指針指向chunk的內(nèi)存繼續(xù)使用時(shí)。修改被釋放chunk的內(nèi)存數(shù)據(jù)時(shí)，就會(huì)破壞free chunk list，從而導(dǎo)致堆溢出漏洞的產(chǎn)生。

漏洞分析

由于busybox多平臺(tái)原因，為了方便調(diào)試，這里我選用靶場(chǎng)linux操作機(jī)進(jìn)行操作。動(dòng)態(tài)調(diào)試過程如下，在gdb調(diào)試后下斷，并attach進(jìn)程，斷點(diǎn)信息如下。

直接按c運(yùn)行，程序要求我們輸入字符串，這里隨意輸入

程序直接斷在了call free處，觀察到RDI為空，我們不用管它。查看堆棧回溯發(fā)現(xiàn)程序是由awk_getline函數(shù)調(diào)用進(jìn)行的，這里就是前面分析中awk_getline函數(shù)獲取用戶輸入。

堆空間堆塊排布信息如下，可以看到我們輸入的"foo"字符串，堆內(nèi)存結(jié)構(gòu)此時(shí)還沒有被破壞，我們繼續(xù)往下調(diào)試。

調(diào)試過程中，釋放的堆塊信息比較復(fù)雜，我們使用bins命令查看當(dāng)前free chunk list。

運(yùn)行到了evaluate函數(shù)處，這里便是源碼中使用nvalloc(xzalloc)函數(shù)分配tmpvars的堆內(nèi)存。

這里直接斷在了case XC(OC_MOVE)里面的copyvar函數(shù)，copyvar的第一個(gè)參數(shù)為L(zhǎng).v，第二個(gè)參數(shù)是R.v。這里L(fēng).v已經(jīng)被修改成了tmpvars的指針，這樣倆個(gè)指針同時(shí)指向了tmpvars的內(nèi)存，后續(xù)會(huì)調(diào)用free函數(shù)進(jìn)行釋放。

si進(jìn)入copyvar函數(shù)，運(yùn)行到call clrvar處，這里的rdi即傳入第一個(gè)參數(shù)的L.v的地址。clrvar會(huì)調(diào)用free函數(shù)進(jìn)行釋放。

運(yùn)行后進(jìn)入handle_special函數(shù)，后續(xù)流程較為復(fù)雜，直接在漏洞觸發(fā)點(diǎn)getvar_i處下斷點(diǎn)。運(yùn)行后，斷點(diǎn)停在了call getvar_i函數(shù)，我們跟入分析。

在getvar_i函數(shù)中，對(duì)0x55555585caa0指針指向chunk進(jìn)行了修改(v->type)。

此時(shí)getvar_i函數(shù)中處理的v->type即為tmpvars free chunk的控制結(jié)構(gòu)，函數(shù)這里直接對(duì)其進(jìn)行了處理，導(dǎo)致堆結(jié)構(gòu)的改變。

此時(shí)0x55555585caa0中數(shù)據(jù)0x55555585caf0被修改，原來的free chunk list已經(jīng)被破環(huán)，修改后0x55555585caa0指向的下一個(gè)free chunk被修改為0x55555585c9f0。

當(dāng)我們進(jìn)行第二次輸入字符串時(shí)，會(huì)繼續(xù)對(duì)堆空間進(jìn)行申請(qǐng)和釋放。當(dāng)申請(qǐng)到0x55555585c9f0地址處的chunk時(shí)，會(huì)對(duì)堆空間進(jìn)行數(shù)據(jù)更改，導(dǎo)致程序崩潰。

0x55555585c9f0地址處已經(jīng)被申請(qǐng)，此時(shí)chunk結(jié)構(gòu)被破壞，gdb插件已經(jīng)無(wú)法識(shí)別剩余內(nèi)容空間的堆結(jié)構(gòu)。

堆塊標(biāo)識(shí)被清空，所以無(wú)法找到對(duì)應(yīng)堆塊的起始位置，所以插件識(shí)別不了。

當(dāng)繼續(xù)往下調(diào)試時(shí)，程序崩潰。

下圖為另一個(gè)poc測(cè)試出現(xiàn)的情況，這里面的topchunk標(biāo)識(shí)被修改為0，當(dāng)堆繼續(xù)申請(qǐng)和釋放時(shí)，程序同樣會(huì)崩潰。

漏洞復(fù)現(xiàn)

下載好busybox后直接使用源碼進(jìn)行編譯安裝

make menuconfig
make
make install

使用已公開的poc進(jìn)行測(cè)試，發(fā)現(xiàn)觸發(fā)了漏洞。

由于busybox在不同系統(tǒng)中的編譯使用，且不同系統(tǒng)編譯后程序開啟的保護(hù)也不同，那么這里獲取執(zhí)行權(quán)限的方式也不同。

總結(jié)

整體分析下來，該漏洞利用性不大，且獲取執(zhí)行權(quán)限的利用方式較為復(fù)雜，但因?yàn)槠淇赡芫哂蝎@取執(zhí)行權(quán)限的情況，請(qǐng)使用busybox漏洞版本的各位用戶盡快升級(jí)到最新版本。

審核編輯：劉清