深度调查CVE-2015-5477&CloudFlare Virtual DNS如何保护其用户

virustracker ·

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

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

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

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

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

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)。

很讽刺的是，这些指针的验证过程真的非常严格：如果这些指针没有指向(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出现的地方了。

现在的问题是，什么时候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_findname 在 DNS_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 != NULL fail， 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总是会验证进入的数据包是不是良性的，确保查询是正常的，并且简化成最简单的形式，接着才会转发。

©乌云知识库版权所有 未经许可 禁止转载
收藏

为您推荐了适合您的技术文章:

  1. WordPress Vulnerability Analysis (CVE-2015-5714 & CVE-2015-5715)
  2. CVE-2015-7547简单分析与调试
  3. MMD-0043-2015 - 多态型ELF恶意软件:Linux/Xor.DDOS
  4. CVE-2015-3795


30
乌帽子 2015-09-29 20:59:10

这个图是什么意思？

回复
感谢知乎授权页面模版