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

背景

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

漏洞原理

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

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

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

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

進入查看發現clrvar對第一個參數進行操作，隨后使用handle_special函數對dest進行處理。進入查看發現clrvar函數調用free函數對內存進行了釋放。

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

接下來返回awk_main函數簡單觀察一下執行流程。發現程序首先進行一系列設置，指定了標準輸入輸出，隨后使用awk_getline獲取用戶輸入，并循環使用evaluate函數進行處理。

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

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

漏洞分析

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

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

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

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

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

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

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

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

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

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

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

此時0x55555585caa0中數據0x55555585caf0被修改，原來的free chunk list已經被破環，修改后0x55555585caa0指向的下一個free chunk被修改為0x55555585c9f0。

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

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

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

當繼續往下調試時，程序崩潰。

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

漏洞復現

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

make menuconfig
make
make install

使用已公開的poc進行測試，發現觸發了漏洞。

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

總結

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

審核編輯：劉清