深度调查CVE20155477&CloudFlare Virtual DNS如何保护其用户

admin 2019年5月13日09:00:24评论337 views字数 5815阅读19分23秒阅读模式
摘要

原文:https://blog.cloudflare.com/a-deep-look-at-cve-2015-5477-and-how-cloudflare-virtual-dns-customers-are-protected/

原文:https://blog.cloudflare.com/a-deep-look-at-cve-2015-5477-and-how-cloudflare-virtual-dns-customers-are-protected/

上周,ISC发布补丁,修复了BIND9 DNS服务器中的一个远程可利用漏洞。这个漏洞会导致服务器在处理某个数据包时发生崩溃。

深度调查CVE20155477&CloudFlare Virtual DNS如何保护其用户

公告中指出道,服务器在处理TKEY类型的查询时出现了一个错误,这个错误导致assertion fail,而这个fail又造成了服务器的崩溃。因为assertion是在查询解析的过程出现的,所以这个问题无法避免:服务器在接收到数据包时,首先要做的就是解析这个查询,然后再根据需要做出相应的决定。

TSIG是DNS服务器使用的一个验证彼此的协议。在这个协议的上下文中用到了TKEY 查询。不同于常规的DNS查询,在TKEY查询的信息中,有一个EXTRA/ADDITIONAL节,在这个节中包含有关于TKEY类型的“meta”记录。

深度调查CVE20155477&CloudFlare Virtual DNS如何保护其用户

因为现在利用数据包已经公开了,所以我觉着我们可以研究一下这个漏洞代码。那我们就看看这个崩溃实例的输出结果:

03-Aug-2015 16:38:55.509 message.c:2352: REQUIRE(*name == ((void*)0)) failed, back trace   03-Aug-2015 16:38:55.510 #0 0x10001510d in assertion_failed()+0x5d   03-Aug-2015 16:38:55.510 #1 0x1001ee56a in isc_assertion_failed()+0xa   03-Aug-2015 16:38:55.510 #2 0x1000bc31d in dns_message_findname()+0x1ad   03-Aug-2015 16:38:55.510 #3 0x10017279c in dns_tkey_processquery()+0xfc   03-Aug-2015 16:38:55.510 #4 0x100016945 in ns_query_start()+0x695   03-Aug-2015 16:38:55.510 #5 0x100008673 in client_request()+0x18d3   03-Aug-2015 16:38:55.510 #6 0x1002125fe in run()+0x3ce   03-Aug-2015 16:38:55.510 exiting (due to assertion failure)   [1]    37363 abort (core dumped)  ./bin/named/named -f -c named.conf 

上面的崩溃代码对我们启示很大,它告诉我们这是由assertion失败导致的崩溃,并且告诉我们出现问题的地方在message.c:2352. 下面是漏洞代码摘要:

// https://source.isc.org/git/bind9.git -- faa3b61 -- lib/dns/message.c          isc_result_t     dns_message_findname(dns_message_t *msg, dns_section_t section,                  dns_name_t *target, dns_rdatatype_t type,                  dns_rdatatype_t covers, dns_name_t **name,                  dns_rdataset_t **rdataset)     {         dns_name_t *foundname;         isc_result_t result;              /*          * XXX These requirements are probably too intensive, especially          * where things can be NULL, but as they are they ensure that if          * something is NON-NULL, indicating that the caller expects it          * to be filled in, that we can in fact fill it in.          */         REQUIRE(msg != NULL);         REQUIRE(VALID_SECTION(section));         REQUIRE(target != NULL);         if (name != NULL) ==>         REQUIRE(*name == NULL);          [...] 

这里,我们找到了一个函数"dns_message_findname",这个函数的作用是根据message section中给定的名称和类型,查找具有相同名称和类型的RRset。这个函数应用了一个很常见的C API:来获取结果,在结果中填充着caller传递的指针 (dns_name_t **name, dns_rdataset_t **rdataset)。

深度调查CVE20155477&CloudFlare Virtual DNS如何保护其用户

很讽刺的是,这些指针的验证过程真的非常严格:如果这些指针没有指向(dns_name_t *)NULL,REQUIRE assertion就会fail并且服务器就会崩溃,也不会尝试恢复。调用这个函数的代码必须要格外小心地把指针传递到NULL dns_name_t *,函数会填充到代码中返回找到的名称。

在非内存安全语言中,当assertion是无效的时候,崩溃就经常出现。因为当出现了异常时,程序很可能就没办法来清理自身的内存了。

所以,在继续调查中,我们通过栈来查找非法调用。接下来就是dns_tkey_processquery,下面是简化摘要:

// https://source.isc.org/git/bind9.git -- faa3b61 -- lib/dns/tkey.c      isc_result_t   dns_tkey_processquery(dns_message_t *msg, dns_tkeyctx_t *tctx,                 dns_tsig_keyring_t *ring) {     isc_result_t result = ISC_R_SUCCESS;     dns_name_t *qname, *name;     dns_rdataset_t *tkeyset;          /*      * Interpret the question section.      */     result = dns_message_firstname(msg, DNS_SECTION_QUESTION);     if (result != ISC_R_SUCCESS)         return (DNS_R_FORMERR);          qname = NULL;     dns_message_currentname(msg, DNS_SECTION_QUESTION, &qname);          /*      * Look for a TKEY record that matches the question.      */     tkeyset = NULL;     name = NULL;     result = dns_message_findname(msg, DNS_SECTION_ADDITIONAL, qname,                       dns_rdatatype_tkey, 0, &name, &tkeyset);     if (result != ISC_R_SUCCESS) {         /*          * Try the answer section, since that's where Win2000          * puts it.          */         if (dns_message_findname(msg, DNS_SECTION_ANSWER, qname,                      dns_rdatatype_tkey, 0, &name,                      &tkeyset) != ISC_R_SUCCESS) {             result = DNS_R_FORMERR;             tkey_log("dns_tkey_processquery: couldn't find a TKEY "                  "matching the question");             goto failure;         }     }      [...] 

这里有两个dns_message_findname调用,因为我们寻找的是传递恶意name的一个调用,所以我们可以忽略掉第一个调用了,因为前面写着name = NULL;

第二个调用就比较有意思了。在先调用了dns_message_findname之后,调用又重新使用了相同的dns_name_t *name,而且也没有把它设置成NULL。这可能就是bug出现的地方了。

深度调查CVE20155477&CloudFlare Virtual DNS如何保护其用户

现在的问题是,什么时候dns_message_findname会设置name,而不返回ISC_R_SUCCESS呢(这样的话if条件就能满足了)?现在,我们一起看一看完整的函数主体。

// https://source.isc.org/git/bind9.git -- faa3b61 -- lib/dns/message.c      isc_result_t   dns_message_findname(dns_message_t *msg, dns_section_t section,                dns_name_t *target, dns_rdatatype_t type,              dns_rdatatype_t covers, dns_name_t **name,              dns_rdataset_t **rdataset) {     dns_name_t *foundname;     isc_result_t result;          /*      * XXX These requirements are probably too intensive, especially      * where things can be NULL, but as they are they ensure that if      * something is NON-NULL, indicating that the caller expects it      * to be filled in, that we can in fact fill it in.      */     REQUIRE(msg != NULL);     REQUIRE(VALID_SECTION(section));     REQUIRE(target != NULL);     if (name != NULL)         REQUIRE(*name == NULL);     if (type == dns_rdatatype_any) {         REQUIRE(rdataset == NULL);     } else {         if (rdataset != NULL)             REQUIRE(*rdataset == NULL);     }          result = findname(&foundname, target,               &msg->sections[section]);          if (result == ISC_R_NOTFOUND)         return (DNS_R_NXDOMAIN);     else if (result != ISC_R_SUCCESS)         return (result);          if (name != NULL)         *name = foundname;          /*      * And now look for the type.      */     if (type == dns_rdatatype_any)         return (ISC_R_SUCCESS);          result = dns_message_findtype(foundname, type, covers, rdataset);     if (result == ISC_R_NOTFOUND)         return (DNS_R_NXRRSET);          return (result); } 

你能发现,dns_message_findname首先使用了findnamet来匹配与目标名称一致的记录,然后用dns_message_findtype来匹配目标类型。在这两个调用之间...*name = foundname!即使dns_message_findnameDNS_SECTION_ADDITIONAL中找到了name == qname的一条记录,但是类型不是dns_rdatatype_tkey这个name也会被填充并返回失败。 第二个dns_message_findname调用会触发恶意name,然后就一发不可收拾了。

的确,补丁只是在第二个调用前添加了name = NULL(不,我们的出发点不是补丁程序,不然还有什么意思)

diff --git a/lib/dns/tkey.c b/lib/dns/tkey.c   index 66210d5..34ad90b 100644   --- a/lib/dns/tkey.c +++ b/lib/dns/tkey.c @@ -654,6 +654,7 @@ dns_tkey_processquery(dns_message_t *msg, dns_tkeyctx_t *tctx,           * Try the answer section, since that's where Win2000           * puts it.           */ +        name = NULL;          if (dns_message_findname(msg, DNS_SECTION_ANSWER, qname,                       dns_rdatatype_tkey, 0, &name,                       &tkeyset) != ISC_R_SUCCESS) { 

让我们再看一下bug触发的流程:

  • 收到一个TKEY类型查询,调用dns_tkey_processquery来解析这个查询
  • 在EXTRA节中找到与查询名称相同的记录,导致填充了name,但是这条记录并不是一个TKEY记录,导致result != ISC_R_SUCCESS
  • 再次调用dns_message_findname在ANS节中查找,现在是通过恶意的name参考
  • assertion *name != NULLfail,BIND崩溃

@jfoote_通过american fuzzy lop模糊测试工具发现了这个bug。模糊测试工具是一个自动工具,能自动向目标程序不断地提交异常输入,直至程序崩溃。你可以通过TKEY 查询+ 非TKEY EXTRA RR的组合来看看服务器最终是怎样崩溃的,并找到这个bug。

Virtual DNS用户是安全的

好消息!CloudFlare Virtual DNS用户的BIND服务器不会受到这次攻击的影响。如果需要的话,我们的自定义Go DNS服务器-PRDNS会首先解析所有的查询,并“消毒”,然后才会把查询转发回原来的服务器。

因为Virtual DNS并不支持TSIG和TKEY(用于认证服务器到服务器之间的流量,并不是递归查询),所以没有必要在查询中转发EXTRA节的记录,Virtual DNS也没有这样做。这样面临的攻击风险就小了很多,而且也无法通过Virtual DNS来利用这个漏洞。

现在还没有什么办法能防御这个漏洞:PRDNS总是会验证进入的数据包是不是良性的,确保查询是正常的,并且简化成最简单的形式,接着才会转发。

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2019年5月13日09:00:24
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   深度调查CVE20155477&CloudFlare Virtual DNS如何保护其用户http://cn-sec.com/archives/60044.html

发表评论

匿名网友 填写信息