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

背景

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

漏洞原理

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

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

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

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

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

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

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

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

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

漏洞分析

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

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

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

堆空間堆塊排布信息如下，可以看到我們輸入的"foo"字符串，堆內存結構此時還沒有被破壞，我們繼續(xù)往下調試。

調試過程中，釋放的堆塊信息比較復雜，我們使用bins命令查看當前free chunk list。

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

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

si進入copyvar函數(shù)，運行到call clrvar處，這里的rdi即傳入第一個參數(shù)的L.v的地址。clrvar會調用free函數(shù)進行釋放。

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

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

此時getvar_i函數(shù)中處理的v->type即為tmpvars free chunk的控制結構，函數(shù)這里直接對其進行了處理，導致堆結構的改變。

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

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

0x55555585c9f0地址處已經(jīng)被申請，此時chunk結構被破壞，gdb插件已經(jīng)無法識別剩余內容空間的堆結構。

堆塊標識被清空，所以無法找到對應堆塊的起始位置，所以插件識別不了。

當繼續(xù)往下調試時，程序崩潰。

下圖為另一個poc測試出現(xiàn)的情況，這里面的topchunk標識被修改為0，當堆繼續(xù)申請和釋放時，程序同樣會崩潰。

漏洞復現(xiàn)

下載好busybox后直接使用源碼進行編譯安裝

make menuconfig
make
make install

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

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

總結

整體分析下來，該漏洞利用性不大，且獲取執(zhí)行權限的利用方式較為復雜，但因為其可能具有獲取執(zhí)行權限的情況，請使用busybox漏洞版本的各位用戶盡快升級到最新版本。

審核編輯：劉清