Cve-2016-2776复现

Cve-2016-2776
背景：
攻击者通过向BIND 9发送精心构造的DNS请求，使其在构造响应包时错误计算所需保留空间的长度，导致后续断言失败进而终止程序，从而可以达到拒绝服务的目的。(当DNS服务器构建对精心设计的查询的响应时，可以触发此特定漏洞，其中响应大小超过默认DNS响应大小512)

当DNS服务器构造DNS查询的响应时，它会在响应缓冲区（默认大小为512）中保留空间，它将按照Answer RR所需的大小增加msg-> reserved。 大小也以msg->reserved大小相加，如果响应缓冲区具有其他资源记录，则大小相同。
如果DNS响应（r.length）流量小于512字节（msg->reserved），则该函数将返回true，但添加固定的12字节头将导致服务终止，如果它超过固定的保留大小 512字节。

攻击原理（结合流量）分析：
UDP DNS响应的标准最大大小是512字节，而DNS_MESSAGE_HEADERLEN（dns头部）是常量值12，512-12=500，如果我们能够使500 reserved <= 512，则能造成dos攻击
操作响应中包含的附加RR的最直接方法是发送一个查询，其中TSIG RR包含一个无效签名。当这种情况发生时，服务器在响应时实际上会回显所有记录。下面的poc向服务器发送一个查询a，其TSIG足够大，以便在编写响应时使服务器在msg->上保留501字节。

而抓包得到的是517字节是因为：
服务器响应中包含的TSIG RR缩短了16个字节。 因此应该添加16个字节来进行补偿。
源码中，走到dns_message_renderbegin ( )时，: msg- >reserver是501，而r.length是512。

Dns_message_renderbegin()在验证缓冲区有足够的空间存储msg->reserved后，它会在其中分配DNS_MESSAGE_HEADERLEN（12）字节。 换句话说，它没有检查在保留msg-> reserved之后是否有足够的空间来存储12个字节。

复现：
启动服务

运行poc

此时服务已经dos

检测方案：addtinal_records的值大于等于517，则可以判定为cve-2016-2776的攻击

详细分析参考：https://blog.infobytesec.com/2016/10/a-tale-of-dns-packet-cve-2016-2776.html