上周，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 != 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总是会验证进入的数据包是不是良性的，确保查询是正常的，并且简化成最简单的形式，接着才会转发。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论