怎么進行CVE-2017-16943-Exim-UAF漏洞分析

本篇文章為大家展示了怎么進行CVE-2017-16943-Exim-UAF漏洞分析，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

0x00 背景介紹

Exim 是劍橋大學開發的一款基于 GPL 協議的開放源代碼軟件，其主要用于連接互聯網 Unix 系統的消息傳輸代理（MTA）服務器。

2017年11月25日，Exim官方修復了一處use-after-free的漏洞，由臺灣安全公司DEVCORE的研究人員Meh發現，CVE編號為：CVE-2017-16943，并公布了一份POC，但是根據我們的分析跟進，該POC必須將配置文件中的dkim開啟才能達到控制EIP，造成進程崩潰的效果。

2017年12月11日，Meh在DEVCORE官網公布該漏洞的具體細節和默認配置下的POC。

360 CERT對此進行驗證，證明可以造成遠程代碼執行，影響范圍廣，危害嚴重。

0x01 漏洞攻擊面影響

1、影響面

根據360CERT全網資產檢索平臺，截止2017年12月15日檢索的結果表明全球有超過一百萬臺服務器上運行著Exim，全球的影響分布圖如下：

2、影響版本

該漏洞影響開啟chunk設置的4.88和4.89版本

3、修復版本

360 CERT建議相關用戶及時下載官方的修復補丁，關閉chunk設置或者更新到4.90版本。

0x02 漏洞詳情

1.   開啟dkim配置下控制rip

exim一共管理著三種堆，定義成枚舉類型的全局變量：

POOL_MAIN:表示主要的分配的堆塊，可以被釋放，消息的處理會在該堆池中分配。

POOL_PERM:表示分配的內存是永久的，直到進程結束才會被釋放，保存一些需要共享的信息,例如配置信息，host信息，在使用這塊堆池分配前會將store_pool改為POOL_PERM，再調用store_get()。

POOL_SEARCH:保存搜索的數據，在search_tidyup、search_open、internal_search_find函數中被使用。

Exim會循環讀取消息，并動態分配內存，申請內存的函數包括：expand_string()、store_get()、string_xxx()，store_get_perm()會使用perm pool。

將配置文件/usr/exim/configure中的“control =dkim_disable_verify”注釋，可以觸發進程崩潰，進而控制rip，分析原因如下：

在receive_msg函數中會判斷是否開啟dkim，如果開啟就會進入dkim_exim_verify_init函數：

dkim_exim_verify_init函數里在perm pool中申請內存：

使得在堆中分配一塊內存，同時不改變current_block[0]中的值，后續對消息處理時會在main pool中分配堆塊，分配一塊0x2010大小的堆塊，釋放后，由于之前perm pool分配的堆塊，使得釋放的堆塊不和top chunk合并，變成一個unsorted bin，此時fd和bk指向main arena區域。再進一次store extend后，通過store_get會獲得指向main arena的指針，之后memcpy對main arena進行寫操作，后續的free操作會造成崩潰，RIP會變成填充的數據。

具體的細節如下圖：

2.   默認配置下控制rip

在devcore公司公布具體細節后，我們對默認配置下如何控制rip進行了分析。其實原理和開啟dkim配置類似，需要在top_chunk前分配一塊在使用的堆塊，防止后面釋放的堆塊和top_chunk合并，作者的poc是利用DATA來發送一個足夠大的數據來擴展堆塊，循環多次后，期間釋放了之前的堆塊，變成了一個大的unsorted bin塊供后續分配。此時top_chunk之前就有了正在使用的堆塊，再利用BDAT命令達到控制rip的目的。

具體控制rip的流程如下：

0x03 漏洞利用驗證

我們根據meh的poc和思路編寫了exp，通過控制rip跳轉到fflush(stdout)，并覆蓋_IO_FILE結構覆蓋成攻擊代碼，將_IO_jump_t 虛表結構體中的(_IO_sync_t, __sync)覆蓋成system函數地址，來執行攻擊代碼。

Exp攻擊效果圖：

0x04 官方補丁

官方補丁判斷要釋放的堆塊是否為最后一個堆塊，如果不是的話，就不能釋放，這樣就達不到UAF的條件，無法觸發漏洞。

上述內容就是怎么進行CVE-2017-16943-Exim-UAF漏洞分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。