深入分析在ISC BIND服务器中潜藏了15年的RCE漏洞

2020年10月，我们收到了一份针对ISCBIND服务器的匿名安全报告。在这份报告中发现的安全问题，实际上基于之前曝出的漏洞CVE-2006-5989，该漏洞影响Apache模块mod_auth_kerb，并且，它最初也是由匿名研究人员发现的。ISCBIND服务器SPNEGO(theSimple and Protected GSSAPINegotiationMechanism，SPNEGO)组件内共享了含有该漏洞的代码，但ISC当时并没有合并相应的安全补丁。15年后，ISC对BIND中的这个漏洞进行了修复，并为其分配了相应的漏洞编号，即CVE-2020-8625。

对于BIND服务器来说，从9.11到9.16的版本都受到该漏洞的影响。并且，攻击者可以在无需身份验证的情况下远程触发该漏洞，进而导致一个4字节的堆溢出。这份安全报告的内容符合TargetingIncentiveProgram的要求，但缺乏获得全额奖金所需的完整exploit。不过，这仍然不失为一个优秀的安全报告，而且这个漏洞也值得我们深入进行研究。

漏洞分析

该漏洞的成因，是位于lib/dns/spnego.c中的函数der_get_oid()存在堆溢出漏洞。

这个函数在(1)处分配一个数组缓冲区。变量len用于跟踪缓冲区中剩余的元素数量。同时，代码在(2)处对前2个元素进行了填充处理，但是，它在(3)处只将len减去了1。因此，循环(4)可以使缓冲区溢出1个元素。data->components的类型是int，所以，这将导致4字节的堆溢出。

触发机制

由于该漏洞存在于SPNEGO组件中，因此，必须在BIND中对TKEY-GSSAPI进行相应的配置。

其中，dns.keytab文件位于bin/tests/system/tsiggss/ns1/中，而example.nil.db文件则是由脚本bin/tests/system/tsiggss/setup.sh生成的。

现在，相应的测试环境已经准备好了。当接收到一个手工请求时，该漏洞就会被触发，并产生以下调用栈：

漏洞利用

这个漏洞的可利用性高度依赖于glibc的版本，而下面的解释是基于Ubuntu18.04和glibc2.27的，后者支持tcache。

首先，我们要确定这个溢出漏洞所能控制的内容：

• 在der_get_oid()中分配的易受攻击的缓冲区的大小和内容是可控的。顺便说一下，当当前请求完成后，该缓冲区将被释放。
• decode_MechTypeList()中有一个while循环，用于重复执行der_get_oid()函数，并且循环次数也是可控的。

有了这两点，我们就可以轻松地操纵堆了。为了准备堆，我们可以耗尽任意大小的tcachebins，并在请求完成后重新对其进行填充。同时，重新填充的分块(chunk)在内存中可以是连续的。这使得内存布局相当有利于通过缓冲区溢出发动攻击。

实现任意写原语

在这个阶段，通过滥用tcache空闲列表可轻松实现任意写原语。

触发一个4字节的溢出来扩展下一个空闲的chunk大小。

在下一个请求中，在受损的chunk中分配内存空间。当请求结束时，它将被移动到新的tcache bin中。

用新的大小再次分配受损的chunk。这时，受损的chunk将与下一个空闲的chunk发生重叠，然后，用一个任意的值覆盖其freelist。

从“中毒的”tcache freelist上分配内存空间。它将返回一个任意地址。

泄漏内存地址

默认情况下，会为BIND启用所有Linux缓解措施。因此，我们首先要搞定ASLR，这意味着我们需要找到一种从内存中泄漏地址的方法。一个可能实现内存泄漏的机会，是利用code_NegTokenArg()函数。该函数用于将响应消息编码到一个缓冲区中，并将其发送给客户端。

位于(5)处的buf是一个临时缓冲区，它的初始大小是1024字节，正好在tcache处理的范围内。而(6)处的outbuf是将被发送到客户端的缓冲区，其大小也在tcache的范围内。如果可以对这两个缓冲区的大小进行tcachedup攻击，那么，在(5)和(6)处的两次malloc()调用将返回相同的地址。在执行(7)处的free()函数之后，一个tcache->next指针将被更新到buf中，但是，这时它已经和outbuf重叠在一起了。这意味着堆指针将泄露给客户端。

理想情况下，位于(6)处的buf_len应该选择得足够大，以避免干扰较小的tcachebins。不幸的是，最大值似乎只有96个字节。由于这个问题，进程根本无法存活，并在客户端得到泄漏的堆指针后不久就会崩溃。因此，我们需要进行更深入的研究，以便来找到一种可以充分利用该漏洞的方法。

漏洞的修复

在BIND 9.16.12和BIND 9.11.28中，已经修复了该漏洞。为了修复BIND9.16，ISC完全放弃了SPNEGO的使用。在BIND9.11中，他们针对原始问题应用了补丁程序。

小结

这个安全漏洞表明，即使软件是开源的，并且得到了广泛使用，漏洞也会存在多年而难以被发现。软件维护人员需要密切监视他们使用的所有外部模块，以确保应用了最新的安全补丁。同时，该漏洞也表明这是一个非常棘手的挑战。ISCBIND是Internet上最流行的DNS服务器，所以，该漏洞的影响范围相当大，特别是该漏洞可以在远程且无需身份验证的情况下触发。我们建议大家尽快更新相应的DNS服务器。

本文翻译自：https://www.thezdi.com/blog/2021/2/24/cve-2020-8625-a-fifteen-year-old-rce-bug-returns-in-isc-bind-server

鸿蒙官方战略合作共建——HarmonyOS技术社区