CVE-2020-8616: BIND未充分限制处理引荐报文(referrals)时的查询数量

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 2020年5月19日,ISC发布了BIND的一个新的漏洞和补丁。老版本的BIND的递归服务器在递归查询过程有可能会发送大量的查询报文,导致递归服务器性能降低或被利用放大攻击流量。

CVE-2020-8616 原文请参考ISC官网网站: https://kb.isc.org/docs/cve-2020-8616
为了技术语言的准确性,技术部分的翻译版本附带了英文原文

影响的版本:BIND 9.0.0 -> 9.11.18, 9.12.0 -> 9.12.4-P2, 9.14.0 -> 9.14.11, 9.16.0 -> 9.16.2。9.17的 实验开发分支:9.17.0 -> 9.17.1。9.13和9.15的所有开发版本分支。所有BIND支持预览版 从9.9.3-S1 到 9.11.18-S1。

严重性: 高

可利用性: 远程可利用

漏洞描述:
In order for a server performing recursion to locate records in the DNS graph it must be capable of processing referrals, such as those received when it attempts to query an authoritative server for a record which is delegated elsewhere.
为了让服务器在DNS图(注:DNS树形结构)中执行递归查询,定位DNS记录,它必须能够处理引荐报文(referrals)。例如递归试图查询一个权威服务器和其上的DNS记录,上级权威服务器会通过引荐报文(referrals)应答方式引导递归服务器去查询位于某地方的权威服务器。

In its original design BIND (as well as other nameservers) does not sufficiently limit the number of fetches which may be performed while processing a referral response.
在BIND的最初设计中(以及其他名字服务器),没有充分限制处理引荐报文时的查询数量。

影响:

A malicious actor who intentionally exploits this lack of effective limitation on the number of fetches performed when processing referrals can, through the use of specially crafted referrals, cause a recursing server to issue a very large number of fetches in an attempt to process the referral.
恶意的参与者故意利用(BIND)处理引荐报文(referrals)时缺乏有效限制的缺陷,通过使用特别设计引荐报文,可以导致递归服务器在处理报文时发出大量的查询报文。(注:安全漏洞的原理具体请参考CZ.NIC 写的文章)

This has at least two potential effects:
这样至少有两个潜在影响:

  • 1.The performance of the recursing server can potentially be degraded by the additional work required to perform these fetches, and
    由于发送了大量的额外查询报文,递归服务器的性能可能被降低
  • 2.The attacker can exploit this behavior to use the recursing server as a reflector in a reflection attack with a high amplification factor.
    攻击者可以利用这个行为来让递归服务器成为反射器来发起反射放大攻击

注:BIND可以放大1000倍。当处理收到的引荐报文,其中包含500个压缩的NS记录,BIND递归同时查询A和AAAA地址。

CVSS 评分: 8.0

变通方法: 无

漏洞利用
我们不知道有任何活跃的漏洞被利用的案例,除了一篇在2020年5月发表的关于这个缺陷的学术论文。

解决方案

升级到与你当前使用BIND版本最接近的补丁版本:

  • BIND 9.11.19
  • BIND 9.14.12
  • BIND 9.16.3

BIND支持的预览版是BIND提供给符合条件的ISC支持客户的一个特殊功能预览分支。

  • BIND 9.11.19-S1

致谢
ISC感谢特拉维夫大学的Lior Shafir和Yehuda Afek以及跨学科中心(IDC) Herzliya的Anat Bremler-Barr发现并报道了这一问题

相关文档
发现这一漏洞的人准备了一篇学术论文来介绍他们的发现,并将其发布在http://www.nxnsattack.com 上。

请参阅ISC的BIND 9安全漏洞矩阵,以获得受影响的安全漏洞和版本的完整列表。

有更多问题请联系

  • 英文可以直接联系ISC官方邮件: security-officer@isc.org.
  • 中文可以联系Alibaba DNS公共服务邮件:pubdns@alibaba-inc.com ,我们可以帮助联系ISC
  • 如果发现BIND有新的问题,你也可以通过以下ISC网址来提交新的漏洞: https://www.isc.org/reportbug/
相关文章
|
Arthas 前端开发 Java
问题排查---应用程序不在接收新请求
关键词:springboot,jstack,Arthas
141 1
|
4月前
|
网络协议 Linux
在Linux中,如何查看 http 的并发请求数与其 TCP 连接状态?
在Linux中,如何查看 http 的并发请求数与其 TCP 连接状态?
|
6月前
|
监控 UED Python
代理IP的可用率一般是怎么来判断的
代理IP的可用率关乎用户体验和效率,涉及连通性测试(检查能否成功连接目标网站)、响应时间(衡量性能,短响应时间代表高可用性)、成功率统计(访问成功的比例显示稳定性和可靠性)、错误率分析(高错误率显示问题)、以及稳定性评估(长期性能表现确保服务连续性)。多种指标综合判断代理服务质量。
|
7月前
|
弹性计算 运维 Shell
统计每个远程IP访问次数
【4月更文挑战第29天】
61 1
|
7月前
|
弹性计算 Shell Apache
|
Shell Perl
查找 80 端口请求数最高的前 20 个 IP 地址,判断中间最小的请求数是否大于 500,如大于 500,则输出系统活动情况报告到 alert.txt,如果没有,则在 600s 后重试,直到有输出为止
查找 80 端口请求数最高的前 20 个 IP 地址,判断中间最小的请求数是否大于 500,如大于 500,则输出系统活动情况报告到 alert.txt,如果没有,则在 600s 后重试,直到有输出为止
109 1
|
运维 安全 网络安全
.NET HttpWebRequest(请求被中止: 未能创建 SSL/TLS 安全通道)和(基础连接已经关闭: 发送时发生错误)问题查找解决
.NET HttpWebRequest(请求被中止: 未能创建 SSL/TLS 安全通道)和(基础连接已经关闭: 发送时发生错误)问题查找解决
1021 0
.NET HttpWebRequest(请求被中止: 未能创建 SSL/TLS 安全通道)和(基础连接已经关闭: 发送时发生错误)问题查找解决
|
监控
zabbix 查询剩余内存一直大于2G的主机
select host,name from hosts where hostid in (select hostid from items where itemid in (select itemid from trends_uint where it...
1061 0