我是如何通過fuzz apache httpd服務發現CVE-2017-7668

新聞 08-09

介紹

在上一篇文章中我通過介紹如何使用American Fuzzy Lop對apache httpd服務進行模糊測試。不過令我吃驚的是，我寫完這篇文章之後，我發現了在fuzz過程中有幾處崩潰的地方。之所以令我吃驚，是因為在我之前進行fuzz的人，都可以發現這一漏洞，不過我卻是第一個提出來，所以我就寫了這一篇博客。

目標

在fuzz過程中發現apache httpd服務在AFL下崩潰掉了，導致出現了很多問題，比如模糊測試程序穩定性下降，模糊測試之外的程序不會崩潰等等。在這篇文章中，我會在展示漏洞的同時嘗試解釋這些問題，最後再對崩潰本身進行一定的說明。

測試用例

由於這只是我自己用AFL來模擬繼續程序的網路模糊測試，所以我沒有考慮太多複雜以及覆蓋範圍廣的例子。

所以，為了獲得大量安裝apache httpd服務的案例，我決定使用wiki中提供的headers進行搜索。

bash招式一:cut命令

我做的第一件事就是使用編輯器將在Request Fields中的兩個表放到一個文本文件中。這一步驟中編輯器不能將tab換成空格，否則cut命令將執行不成功。我選擇的文件名為wiki-http-headers，將內容寫入後，我們可以選擇第三列的表，命令如下，不過請注意，cut默認分隔符是tab：

cat wiki-http-headers | cut -f3 | grep ":" | sed "s#Example....##g" | sort -u

bash招式二：for命令

現在我們已經學了第一個招式，現在我們使用迭代的方法將每一個header都獨立成行，以及每行創建一個測試用例。熟悉bash用戶肯定知道如何做到這一點，命令如下：

a=0 && IFS=$ n && for header in $(cat wiki-http-headers | cut -f3 | grep ":" | sort -u); do echo -e "GET / HTTP/1.0rn$headerrnrn" > "testcase$a.req";a=$(($a+1)); done && unset IFS

我來簡單快速的解釋一下這一條命令，有一個叫做內部欄位分隔符的東西:IFS，它是一個環境變數，用於分割各個欄位。默認情況下，IFS可以被認為是空格，tab，以及換行符。IFS在遇到空格時，會干擾頭文件進行分割，因為for命令會遍歷給定的文件列表，所以這就是我們為什麼將IFS定義成換行符的原因。現在我們已經寫好迭代，並且將每一個頭文件都寫入到不同的文件當中去了。

bash招式視頻詳細講解：https://asciinema.org/a/12d5frpz4sqgwr2azyugrhrm3/embed?

模糊測試

現在我們已經收集了足夠多的測試用例，所以我們現在可以開始模糊測試了。這一部分的篇幅比較少，因為上一篇文章中已經介紹了足夠多關於模糊測試的內容，基本的步驟為：

1.下載apr, apr-utils, nghttpd2, pcre-8以及 Apache httpd 2.4.25

2.通過以下命令安裝依賴：

sudo apt install pkg-configsudo apt install libssl-dev

3.為apache打補丁：https://gist.github.com/n30m1nd/ec19fc17c6293be303b85a998cd05aa9

4.編譯相應的標誌，以及安裝路徑

現在一切都準備好了，開始進行模糊測試了，正如以下視頻可以看到，經過一點點改進，崩潰並不需要多長時間：

值得一提的是我被這一崩潰欺騙過一次，因為之前我已經介紹過這種測試案例，也知道他很快就會崩潰。之後我才在檢查AFL文件夾的穩定性以及可變行為中通過honggfuzz，radamsa以及AFL組合發現這一測試案例的。

崩潰解釋

對第一次測試結果不滿意

首先，在測試中遇到崩潰測試案例時，必須檢測他是不是存在漏洞，那麼現在讓我們來試試吧：

視頻如下：https://asciinema.org/a/sfcFzCytHGmbZU4YkjAM8aY5t/embed?

不過..崩潰沒有在apache外部顯示，那麼發生了什麼呢？

故障排除

有下面幾件事情我們需要做：

首先，我們現在在持續模式中進行模糊測試：

這就意味著我們的測試案例確實讓軟體進行崩潰了，但是這只是很多崩潰中的一個。在我們這種情況中,__AFL_LOOP設置的值已經超過9000。對於不知道設置變數值的情況，我們可以通過迭代確定這一變數值，比如輸入8999時，軟體沒有崩潰，不過輸入9000之後，軟體崩潰，那麼現在只有一個崩潰案例。

第二件要考慮的事為AFL報告的穩定性：

在模糊測試中，我們得到的報告穩定性越來越低。比較低的穩定性會時AFL在代碼中使用隨機數，或者日期函數，甚至為初始化的內存。

第三件事為我們分配給模糊測試進程的內存:

這種情況下由於我們使用」-m none」參數運行afl因此內存使用是沒有限制的。但是在其他情況下，內存使用可能會產生溢出，然後訪問沒有初始化的內存。

判斷__AFL_LOOP變數值

為了測試我們第一個假設，我們需要測試更多的崩潰案例。縮小參數值，有助於減少時間去尋找新的路徑，更加便於測試。

現在驗證我們第二個假設

測試過程目標：保持穩定

在測試過程中，一旦越來越多的AFL進入到崩潰的測試用例，我們可以檢查崩潰性是否下降，我們可以了解到內存和崩潰存在某種聯繫。為了測試我們是否真的使用了未初始化的內存，我們可以使用一個工具，名為Valgrind。

Valgrind是由多種程序進行組合，並且對你的程序進行檢查。默認情況下，它會使用」memcheck」，一種檢查內存管理的工具。

在debian8中，只需要執行下方命令就可以：

sudo apt install valgrind

安裝完成之後我們需要在valgrind下運行apache，命令為：

NO_FUZZ=1 valgrind -- /usr/local/apache-afl-persist/bin/httpd -X

NO_FUZZ環境遍令是由補丁中的代碼進行讀取，是為了防止模糊測試進入死循環。在啟動apache之後，我們需要將測試用例發送到apache服務中。希望這一步驟能夠驗證我們第二個假設，

視頻地址為：https://asciinema.org/a/tdOiIZZDYpXafeeJiQiRuQ3jp/embed?

可以看到，apache確實在使用沒有初始化的變數。不過這個時候apache沒有崩潰，那麼現在使用之前產生的所有測試用例進行apache測試：

視頻地址為：https://asciinema.org/a/s4HRv61oFcNCmbdQejYVEMGWt/embed?

漂亮，現在出現崩潰了，我們可以進行下一步判斷了

找到源頭

我們做了一個快速的分析，看看是哪一個header導致的崩潰

gdb+valgrind

然後在另外一個終端中，發送我們觸發錯誤的內容：

cat crashing-testcase.req | nc localhost 8080

最後，在第三個終端中，啟動gdb，並進入到valgrind進程中：

target remote | /usr/lib/valgrind/../../bin/vgdb

現在我們就可以觀察到崩潰時，apache的狀態到底是什麼：

在圖片中，1693行爆出了第一個錯誤，我的直覺告訴我s變數是產生錯誤的原因，因為在累加的過程中沒有對的值除了*s判斷指向空，其餘沒有任何安全性檢查。由於s在編譯過程中被優化，所以我們需要通過上一級檢查s將要指向的conn變數。給讀者留下一個小練習，為什麼pwndbg所示的內容跟「bt」命令所顯示的不同。

在下一張圖片當中，請記住上圖中兩個高亮的變數值：0x6e2990c和8749