在研究IVI和TBOX安全的时候经常能遇到DNSmasq服务，而这些DNS的版本往往较低。本篇是我分析CVE-2017-14491的心路历程，作为一个只对DNS有初步了解的情况下，如何一步步通过信息来找到漏洞原理，以此篇来提高自己漏洞分析能力及帮助自己以后少踩坑，分析DNSmasq的主要原因是因为我们目前挖物联网的漏洞主要通过httpd等web端进行挖掘，这些终端还有没有一些其他的渗透方式，为此找到了DNSmasq。
POC：https://github.com/google/security-research-pocs/blob/master/vulnerabilities/dnsmasq/CVE-2017-14491-instructions.txt
分析参考：https://zhuanlan.zhihu.com/p/30472217
DNSmasq是一个小巧且方便地用于配置DNS和DHCP的工具，适用于小型网络，它提供了DNS功能和可选择的DHCP功能。它服务那些只在本地适用的域名，这些域名是不会在全球的DNS服务器中出现的。DHCP服务器和DNS服务器结合，并且允许DHCP分配的地址能在DNS中正常解析，而这些DHCP分配的地址和相关命令可以配置到每台主机中，也可以配置到一台核心设备中（比如路由器），DNSmasq支持静态和动态两种DHCP配置方式，许多路由器都会使用到DNSmasq。
gdb dnsmasqset args -p 53535 --no-daemon --log-queries -S 127.0.0.2 --no-hosts --no-resolv
python test.py 127.0.0.2 53
从这里看到是iface->found = 0出现了错误，从左边变量可以看见iface不是一个地址，而是0x5a5a5a5a5a5a5a5a（”ZZZ……”)
说明payload将iface->next溢出了，再来看看daemon->interfaces里面的内容，如下图：
很明显里面保存了网卡的信息，next里面的地址是0x5555558df830,那就跟着查看next，直到next是0x5a5a为止
现在可以看到该地址里面保存的数据，从数据可以看出该结构体给我们的脚本溢出了，对应的地址是0x5555558df730，查看后发现的确给溢出了，很明显这个地址是堆
查看栈回溯，主要是通过check_dns_listeners进行调用的
这里主要是reply_query和receive_query值得我们注意，因为这里是处理我们dns请求的函数，重点还是要跟到reply_query，查看payload主要处理逻辑，进入reply_query看到recvfrom，这里应该就是接收payload的地方，将接收到的数据保存到daemon->packet
查看dnsmasq->packet，保存数据地址是0x5555558de380，数据大小是0x1000，也就是说0x5555558de380-0x0x5555558df380都是我们数据存储的地址。
稍等，0x5555558df380和0x5555558df730也就相差0x3b0，也就是说我们溢出的地方很有可能就在0x5555558df380，所以在崩溃的地方再次查看0x5555558df380的数据
看来我想的没错，packet已经溢出了，那么现在问题是需要定位溢出函数在哪里了，整个数据处理逻辑那么多，我们一步一步去跟和盲目下断点显示是很消耗耐心的一件事情，说不定你跟了十几回你就麻木了（诶，我跟到哪里了，我在干嘛）这时候我就想到了硬件断点，既然它溢出了，那么它肯定在0x5555558df380读写数据了，我们就将硬件断点设在0x5555558df380就好了
可以看见在add_resource_record这里断下了，而p所指的内容是0x5555558df382,也就是该函数往堆外的地方写数据了，接着用bt看函数调用
可以看到看到函数调用链为receive_query->answer_request->add_resource_record，且调用位置是rfc1035.c:1851
从名字和函数参数可能猜测是将cache_get_name(crecp)的值放入到ansp中
在answer_request下ansp的值0x5555558df380，也就是堆溢出的地方，那么断在这里的时候我就想:为什么需要两次才能触发堆溢出，那么什么情况下才会用这个函数逻辑
而我经过试验发现rfc1035.c:1851add_resource_record第一次是没有调用，而第二次才调用，cache_get_name是什么。再回头看看DNS处理过程，有这么一句话:
DNS拿到请求后，先检查一下自己的缓存中有没有这个地址，有的话就直接
返回。这个时候拿到的ip地址，会被标记为非权威服务器的应答。
那么这个cache就是我们第一次查询时保存的内容也就是我们的payload，而第二次是返回的cache的内容，但是问题又随之而来了，明明我们第一次返回的数据是没有造成堆溢出的，而第二次却溢出了，这是为什么？
这是第一次发送数据的数据包，可能第一次看没啥感到奇怪的，可是再仔细看看，你会发现DCBBEEEE.DDDD.CCCCCCC.AAAA.BBBB.com在wireshark解析的窗口出现了好几次，而我们的数据包才出现了一次，之后一些奇怪的编码，那么就是这里就关注到rfc1035的规范了，它会将一些重复Answers进行压缩以减少数据包的大小，而再回头看看add_resource_record进行循环处理的时候的效果，我们可以进行对比查看数据包有何不同
我们可以发现每一次处理之后都将Answer中name解析开来了，导致整个数据包一下子溢出了，这就是溢出的原因的所在，导致我们可以控制到其他位置
这篇文章主要是分析DNSmasq漏洞点在哪，为什么会溢出，我把分析的主要点都放在里面，我觉得还是比较新手向的，有兴趣的可以详细阅读和查看。但由于篇幅实在过大，我没有将其他分析点放在这里，有问题可以和我联系。
这次漏洞分析总体是参考Larrxi给出的CVE复现过程，但有些地方和它那部分有所不同，比如漏洞崩溃点，复现的思路等等，这次复现给了我很大的提高，踩了很多坑，也逐渐找到了很多漏洞复现的思路，这个漏洞最终可以实现远程命令执行，但由于最近实在太忙了，没有继续整理，后续有时间我会尝试实现远程命令执行，并接下来会分析其他相关漏洞，敬请期待。
原文始发于微信公众号（天问实验室）：CVE-2017-14491 DNSmasq 堆溢出分析
