Cve-2015-5477复现

Cve-2015-5477

背景：
在9.9.7-P2之前的ISC BIND 9.x和9.10.2-P3之前的9.10.x中命名，允许远程攻击者通过TKEY查询导致拒绝服务( REQUIRE断言失败和守护程序退出)。

分析：
分析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_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，也就不会出现崩溃的现象。

复现：
靶机启动：

执行exp

导致了dos

流量分析

Poc发出了一个dns请求数据包，使用tkey类型的查询服务（一个畸形dns的tkey查询请求），导致BIND9服务在处理畸形数据时调用dns_tkey_processquery -> dns_mssage_findname -> isc_assertion_failed 函数，进而导致程序退出。