1 引言

2018年11月初，国内某云解析服务提供商出现大规模服务不可用故障，在业界引起了不小的震动，以下是官方的故障复盘公告：

技术复盘中很明确地说明了此次故障的起因：大量恶意请求报文攻击触发了软件的bug或漏洞，导致解析服务不可用。

作为域名解析保有量亚洲第一、全球第二的权威域名托管服务商，【阿里DNS团队】打造的阿里云云解析产品和服务(https://https://help.aliyun.com/product/29697.html)，一直致力于通过技术的力量让整个解析服务更加稳定、更加安全和更加快速，在用户服务体验上持续改进。

【阿里DNS团队】在很久之前就已经认识到恶意报文防御在整个DNS系统安全稳定保障工作中的重要性，也花了非常大的精力在这个方面做了很多的研究和实践，下面就简要介绍一下我们在DNS代码白盒Fuzzing测试方面的一些工作。

2 技术方案选型

恶意报文攻击的核心在于攻击者利用了软件处理数据报文的漏洞或者bug，导致软件执行异常或者异常退出，进而导致服务不可用。恶意报文攻击防御要解决的核心问题是尽可能早和尽可能全的发现软件中存在的漏洞，因此需要系统的方法和工具来解决这个问题。

而软件漏洞挖掘属于软件安全或者代码安全的范畴，而阿里巴巴集团安全团队的同学在软件漏洞挖掘领域有非常成熟的可工程落地的经验，因此我们可以利用这些已有的工具和方法帮助我们高效地挖掘DNS软件的漏洞。经过分析和比对，我们最终选定的方案是通过Libfuzzer对DNS软件进行白盒Fuzzing测试。

那么我们为什么使用LibFuzzer呢？

LibFuzzer是一种支持持续执行，基于代码覆盖率的引导式模糊测试引擎。LibFuzzer与被测试的代码链接，然后通过特定的模糊入口（也称为“目标函数”）将模糊输入的样例集提供给LibFuzzer。模糊器跟踪代码会执行到哪些代码块并且收集程序崩溃，内存溢出，内存泄漏等错误，同时对输入数据根据代码覆盖率产生突变，以便最大化覆盖代码达到模糊测试的目的。LibFuzzer的代码覆盖信息由LLVM的SanitizerCoverage指令执行提供。

LibFuzzer相比其他模糊测试平台有如下几个优势：

• 基于代码覆盖率的引导式模糊测试引擎，相比其他黑盒模糊测试平台如peach，codenomicon等商用工具，其成本低廉，并且代码路径覆盖更加自主可控。
• LibFuzzer在对网络协议进行模糊测试时不会解析完成后退出，并且LibFuzzer的输入为一串指定长度的字节序列，模糊测试改造更简单，更适合网络协议白盒fuzz测试的场景。
• 原有单元测试用例改造简单高效，可以按照统一框架生成新的单元测试，提高原有测试资产质量和问题发现概率。
• 基于地址消毒剂技术进行内存监控，能过发现传统测试方法很难检测到的深层次内存溢出和少量内存泄露问题。

3 实战案例

数组越界异常是一种非常不好发现的运行时异常，代码编译阶段是不容易被发现的，一般隐藏的也比较深，bug重现的触发条件一般也比较严格，测试输入构造起来难度相对比较大，是一种典型的恶意报文攻击的目标。那么我们事先在DNS解析代码里面构造了几处数组越界的漏洞，看看通过LibFuzzer大神是否能够帮我们快速发现它们的藏身之处。

3.1 环境准备

源码编译LibFuzzer很是麻烦，幸运的是Clang在6.0版本之后已经天然集成了LibFuzzer，这样就只需下载新版本的Clang即可。如果觉得Clang源码安装也很麻烦可以直接选择编译好的release版本。Clang下载链接http://http://releases.llvm.org/download.html

3.2 接口改造

环境配置完毕之后开始进行模糊测试改造，被改造的目标函数要遵循一下几个要求：

• 被测代码必须能接受任意输入（大，小，非法）。
• 被测代码不能有执行exit()的分支
• 如果使用多线程，多线程要在被测函数退出时join。
• 被测代码不应该修改任何全局状态。
• 被测代码的执行速度要尽可能的快，避免高复杂度的运算，记日志等。

我们选择了DNS报文的入口函数，即解析DNS报文的接口进行模糊改造，改造代码如下：

由于被测程序基于DPDK开发，为了提升模糊测试的效果，需要将DPDK也进行改造。DPDK原生支持Clang编译，需修改dpdk/mk/toolchain/clang/rte.vars.mk

执行dpdk-setup.sh

选择12使用Clang编译DPDK。由于解析DNS报文的接口在业务流程上属于偏上层的接口，对其他代码有依赖，为了单独测试这一个接口，需要把其他依赖代码编译成静态库供LibFuzzer调用。

准备工作都完成之后可以编译fuzz taget了。

3.3 开始测试

准备工作都就绪，现在可以测试了。

首先不指定语料库直接执行编译获得的可执行程序：

运行了一会儿就发现了一处越界错误：

3.4 分析异常

发现问题，解决问题，我们再来看代码，问题出现在函数adns_dname_wire_check，该函数的作用是检查DNS query name和合法性，并且把query name都转成小写(DNS协议不区分大小写)，其中问题出现在这么一段代码中：

因为DNS协议规定一个域名wire format的最大长度为255字节，因此lower_name是一个长度为255字节的数组，用来存转小写后的query name，在给lower_name数组循环赋值的时候没有判断wire_len是否已经越界，如果遇到超长非法域名则lower_name数组会写越界。lower_name是一个局部数组，写越界就会写坏后面的栈空间，是一个高危风险。

3.5 测试结论

可见，LibFuzzer非常快速地帮我们发现了我们事先构建的数组越界异常，让我们在代码发布前就可以及早发现代码异常。

为了提高模糊测试效率，也可以指定语料库运行fuzz测试。语料库可以使用CZNIC收集的DNS报文的集合，https://github.com/CZ-NIC/dns-fuzzing。

执行方法：

针对DNS报文解析接口的fuzz测试最终发现了全部的数组越界异常。限于篇幅原因，本文不逐一分析。

4 写在最后

(1) DNS稳定性大于天

DNS作为网络基础服务，又是一种相对陈旧的网络协议，很容易受到黑客攻击，这几年针对DNS的攻击层出不穷，而一旦DNS出现了问题，影响波及范围广，影响力大，因此DNS是我们必须坚守的阵地。打铁还需自身强，在和攻击者的博弈中，需要对开发运维各个环节多维度收敛问题，尽力将风险降到最低。

(2) 不积跬步，无以致千里

Fuzz测试就是一个很好的从软件本身出发，查漏补缺的入口。虽然结合代码的白盒模糊测试虽然效果很好，但是需要按照接口函数逐个改造测试，工程量巨大，整个测试体系的建立是一个慢工出细活的过程，需要慢慢积累。

【阿里DNS团队】始终将软件可靠性放在第一位考虑，持续在软件可靠性上进行资源投入，通过黑盒+白盒结合的方式，以更高性价比的方式持续挖掘漏洞。

5 参考资料

http://llvm.org/docs/LibFuzzer.html