BIND9 Dos CVE-2015-5477分析
1. 背景
隐藏在開源軟體BIND中named的嚴重安全漏洞，遠端攻擊者通過發起畸形的TKEY查詢，可對DNS伺服器造成DoS拒絕服務( REQUIRE斷言失敗和守護程式退出)。BIND是目前部署在域名伺服器中應用廣泛的開源軟體之一，支援各種 UNIX 平台和 Windows 平台。
2. 受影響版本
ISC BIND 9.1.0 ->9.8.x，9.9.0 -> 9.9.7-P1，9.10.0 -> 9.10.2-P2
3. 分析
分析BIND9源碼中的dns_tkey_processquery和dns_mssage_findname函數。
dns_tkey_processquery函數從dns_tkey_processquery名稱可知，該函數是對類型為TKEY的dns請求做解析，即對下圖中結構做解析：
檢視BIND9源碼，如下圖所示：
從dns_key_processquery函數可知，在函數内部兩次調用了dns_message_findname；其中dns_message_findname函數大緻意思是根據第二個參數DNS_SECTION_ADDITIONAL查找比對的第三個參數qname，如果找到就放在第六個參數name中，并将傳回結果儲存到result中；第一次調用dns_message_findname時，傳入的第二個參數是DNS_SECTION_ADDITIONAL,第三個參數查詢的字元串，如果找到對應的字元串就放入name中，結合資料包，如圖所示：
繼續看看dns_message_findname函數的實作：
看看該函數，函數作用已經說過了。第一次調用時在DNS_SECTION_ADDITIONAL結構中查找和參數qname相同的字元串。
圖中标1處：在dns_message_findname函數中先是判斷name是否為空，圖中标1的位置在第一次調用dns_message_findname之前，name=null,如上圖，但是在調用dns_message_findname函數裡面，此時的name已經變成了調用之前name的位址，也就是說，參數中的name是調用之前name的位址，是以在dns_message_findname函數内部标1的位置滿足條件即name!=NULL,*name==NULL,是以此時在标1處不會出現斷言錯誤。
圖中标2處：在運作到圖中标2處，函數findname 根據傳入的參數在DNS_SECTION_ADDITIONAL結構中查找qname對應的字元串，剛好有該字元串，是以這裡傳回了成功，也就是ISC_SUCCESSED。
圖中标3處：在運作到圖中标3處，測試name!=NULL,name=foundname,也就是給調用dns_message_findname之前的那個name賦了值。
圖中标4處：在運作到圖中标4處，通過dns_message_findtype函數查找在DNS_SECTION_ADDITIONAL結構有沒有對應的TKEY類型。從下圖可以在DNS_SECTION_ADDITIONAL結構中的類型為TXT類型，是以這裡會傳回錯誤。
從第一次調用dns_message_findname結果來看，如果queries結構和additional結構中的name字段相同，但是additional結構的type字段隻要不是TKEY就會傳回錯誤。
二次調用dns_message_findname
由于第一次調用dns_message_findname函數失敗，根據dns_message_findname函數的流程會進入第二次調用dns_message_findname函數如下圖所示：
從代碼中看出在第一次調用dns_message_findname之前name=NULL,經過上面的分析，在經過第一次調用後name已經賦了值（見圖1.1中标3的位置）。那麼在第二次進入dns_message_findname函數後，運作到圖1.1中标1的位置中時，斷言REQUIRE (name == NULL) ;name已經有值，測試的斷言就會不成立導緻程式退出。
更新檔對比
從官方給出的更新檔對比來看，在第二次調用dns_message_findname之前再次将name置空，這樣在第二次運作斷言語句時name=NULL，也就不會出現崩潰的現象。
4. 複現
确定靶機
啟動metasploit環境，在metasploit環境中配置CVE-2015-5477的子產品，配置完成後，啟動抓包軟體：
在所有環境準備好後，啟動CVE-2015-5477子產品，從運作結果來看，該子產品已經正常發起了攻擊，并且顯示攻擊成功：
檢視抓取的資料包情況：
從抓包情況來看，metaploit子產品發出了一個DNS請求資料包，使用TKEY類型的查詢服務。
5. 檢測