Apache CVE-2017-7659漏洞重現及利用分析

新聞 07-08

近日，apache在其網站發布了最新的安全公告，其中涉及多個漏洞。針對CVE-2017-7659漏洞的介紹是這樣的：

A maliciously constructed HTTP/2 request could cause mod_http2 to dereference a NULL pointer and crashthe server process.

可以看到這是apache WEB伺服器（httpd）中的一個HTTP 2.0協議處理的漏洞。未然實驗室安全研究人員針對此漏洞的技術細節和利用方法進行了深入的研究，歡迎安全愛好者們一起分享和討論。

0x01補丁分析

在redhat的bugzilla上可以找到該漏洞：

https://bugzilla.redhat.com/show_bug.cgi?id=1463199

在github上有對該漏洞的修復提交：

https://github.com/apache/httpd/commit/672187c168b94b562d8065e08e2cad5b00cdd0e3

修改前後的代碼差異比較如下：

可以看到，修復內容很簡單，就是增加了對h2_request_rcreate函數返回值的判斷。官方推薦升級到2.4.26修復漏洞。

0x02漏洞成因

從https://archive.apache.org/dist/httpd/httpd-2.4.25.tar.gz

下載到有漏洞的伺服器代碼後，通過補丁的修改進行漏洞成因的逆向分析。

首先查看漏洞函數 h2_stream_set_request_rec，發現是調用h2_request_rcreat創建http 2.0請求的數據結構req，h2_request_rcreat執行失敗時req為空，此時在日誌函數ap_log_rerror中直接解引用req導致進程崩潰：

繼續查看函數h2_request_rcreate，看到首先會把req置為0，然後判斷4個變數

r->method**

，scheme

，r->hostname

，path**，任何一個為空則返回失敗，而此時req還是0，就會導致進程崩潰：

那麼這4個變數是哪一個為空導致的漏洞呢？scheme是先判斷了是否為空再賦值的，首先排除；path是從r->parsed_uri中解析出來，解析函數apr_uri_unparse在其它地方有多次使用，直覺path也不會為空；r->method保存請求的方法欄位，在HTTP請求中必須存在，因此也不應該為空；因此只有r->hostname，保存請求的主機名，也就是域名，可能為空。

我們知道，HTTP請求中，有2個地方可以表示主機名：

1) 請求的路徑以完整URL方式表示，URL中包含主機名，例如GET http://www.example.com/ HTTP/1.1，這裡主機名就是 www.example.com。伺服器中是在ap_parse_uri函數中解析這種主機名的

2) 在Host請求頭中包含主機名，例如：

GET / HTTP/1.1

Host: www.example.com

伺服器中是在fix_hostname函數中解析這種主機名的

分別審計 ap_parse_uri 和 fix_hostname 函數，發現如果請求中沒有Host頭，那麼r->hostname確實是空。但是伺服器也考慮到了這種情況，在 ap_read_request 函數中做了判斷：

這裡的判斷邏輯，如果滿足下面2個條件之一

1) r->hostname為空，且請求的HTTP版本大於等於1.1

2) 沒有Host頭，且請求的HTTP版本等於1.1

就會立刻回復400狀態碼的錯誤頁面，並不會觸發後面的漏洞。在注釋里也說明了，HTTP/1.1的RFC2616的14.23節中明確指明，HTTP/1.1請求必須包含Host頭。

但是，開發者是不是忘了什麼，HTTP還有1.0版本啊，且HTTP/1.0和HTTP/1.1的處理流程一樣，雖然HTTP/1.0確實沒有規定請求必須包含Host頭。

因此**

HTTP/1.0

請求是可以沒有Host

頭的，程序會一直按照流程執行，最終執行到h2_stream_set_request_rec

函數，此時r->hostname

為空，從而觸發漏洞。**

0x03漏洞驗證及漏洞利用

綜合上面的分析，該漏洞利用成功需要如下條件：

1) 伺服器支持HTTP/2

2) 請求是HTTP/1.0版本

3) 請求中沒有Host頭

伺服器配置

在server上要配置開啟HTTP/2功能，使用apache默認的站點配置，在配置文件中首先載入mod_http2.so:

然後加入下面配置，重新啟動apache httpd就可以了:

驗證POC

驗證時，我們首先起一個單一進程的apache httpd服務，方便驗證進程崩潰後的效果：

正常訪問，返回歡迎頁面：

將構造的POC通過burpsuite發送：

果然超時沒有響應，同時在伺服器上發現httpd進程已經崩潰：

再次訪問伺服器時，頁面已經無法訪問了：

漏洞利用

在上一節，我們已經驗證了在單一進程模式下，如何通過該漏洞導致apache伺服器異常終止。但是通常情況下apache伺服器在啟動時，會同時啟動多個工作進程：

而且當worker進程崩潰時，apache會自動啟動新的worker進程。那麼在真實的網路環境中，黑客會如何利用此漏洞對伺服器進行攻擊呢？

我們嘗試編寫了一個多線程(並發100個線程)的程序，同時發起多個畸形請求，以不斷觸發後台worker崩潰，並讓apache伺服器不斷陷入重新分配worker的處理之中：

執行腳本時，發起的請求：

請求發起後，我們發現，並不需要特別的並發連接，便可以讓伺服器進入拒絕服務狀態：

0x04 漏洞影響

在apache的漏洞公告中，只有2.4.25版本的httpd伺服器受此漏洞影響。但是根據未然實驗室的測試，從2.4.17開始的所有版本的httpd伺服器，受到這段POC攻擊時都會崩潰，而httpd也是從2.4.17版本開始支持HTTP 2.0協議的。因此可以說這個漏洞會影響httpd的所有支持HTTP 2.0的版本，未然實驗室強烈建議用戶更新到最新的2.4.26版本。

2.4.25之前的版本代碼與2.4.25版本不盡相同，以2.4.17為例，在h2_request_rwrite函數中：