☰

Glibc 中 getaddrinfo() 的错误缓解

tag-icon • tag-icon linux security bind dns-hosting
Glibc 中 getaddrinfo() 的错误缓解

遇到了一个开发今天，我遇到了一个 glibc 漏洞，它涉及 getaddrinfo() 调用以进行 DNS 解析。我在两个面向互联网的 Bind9 机器上运行 Ubuntu 12.04。我不确定我是否完全理解了这个漏洞，但它似乎是由恶意 DNS 服务器的大量回复引起的。其中一个缓解措施是“防火墙丢弃大于 512 字节的 UDP DNS 数据包”因此我在 DNS 服务器上配置了 netfilter，以丢弃来自或去往端口 53 的任何 UDP > 512 字节： -A INPUT -i lo -j ACCEPT -A INPUT -p udp --sport 53 -m length --length 511:65535 -j DROP -A INPUT -p udp --dport 53 -m length --length 511:65535 -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

有没有更好的方法可以通过绑定设置或其他方式来做到这一点？我已经用 scapy 测试了规则，它确实阻止了在端口 53 上抛出的 UDP 数据包 > 512。

根据回复更新： -A INPUT -i lo -j ACCEPT -A INPUT -p udp --sport 53 -m length --length 949:65535 -j DROP -A INPUT -p udp --dport 53 -m length --length 949:65535 -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

和/etc/bind/named.conf.options

options {
   ...
   // 2016-02-17 - tmb - glibc exploit mitigation
   edns-udp-size 900 ;
   max-udp-size 900 ;
};

更新2: 正如指出的那样阿德雷下面，Cloudflare 尝试了上述技术，虽然无法传输整个有效载荷，但内存损坏仍然是一种可能性。我想我会研究一下未绑定。

答案1

如果您在本地运行 bind，这将为您提供一个测试：

dig @127.0.0.1 tcf.rs.dns-oarc.net txt

如下所述：https://www.dns-oarc.net/oarc/services/replysizetest。

您将收到如下答复：

root@myhost:~# dig @127.0.0.1 tcf.rs.dns-oarc.net txt

; <<>> DiG <<>> @127.0.0.1 tcf.rs.dns-oarc.net txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61575
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 26, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
;; QUESTION SECTION:
;tcf.rs.dns-oarc.net.           IN      TXT

;; ANSWER SECTION:
tcf.rs.dns-oarc.net.    60      IN      CNAME   tcf.x981.rs.dns-oarc.net.
tcf.x981.rs.dns-oarc.net. 59    IN      CNAME   tcf.x986.x981.rs.dns-oarc.net.
tcf.x986.x981.rs.dns-oarc.net. 58 IN    CNAME   tcf.x991.x986.x981.rs.dns-oarc.net.
tcf.x991.x986.x981.rs.dns-oarc.net. 57 IN TXT   "Tested at 2016-02-17 15:44:36 UTC"
tcf.x991.x986.x981.rs.dns-oarc.net. 57 IN TXT   "xx.xx.xx.xx DNS reply size limit is at least 991"

您可以添加绑定选项

options {
  ...
  edns-udp-size 1024 ;
  max-udp-size 1024 ;
};

在文件named.conf中

如下所述：https://labs.ripe.net/Members/anandb/content-testing-your-resolver-dns-reply-size-issues。

我也会将其与其他缓解措施结合使用。

答案2

尽管丢弃大于 512 字节的 UDP DNS 数据包的防火墙。减轻漏洞（特别是通过 UDP，TCP 仍然可以成为攻击媒介）这也是不正确的行为，反而会破坏其他功能。

自从引入 EDNS0 以来，DNS 规范中就没有这样的限制，只需丢弃数据包就会导致有效流量中断。

birdwes 建议，配置一个解析器名称服务器来限制返回给客户端的响应大小是一种更好的方法，因为客户端至少会根据规范得到适当的通知（截断响应），而不是只是沉默并最终超时，但是正确的解决方案是安装修补的 glibc（这就是问题所在，大小没有错误）。

答案3

经过一些测试，CloudFlare 确定限制 DNS 数据包的响应大小和关闭 EDNS0 支持无法修复 CVE-2015-7547。您可以使用作者的 PoC 代码进行测试，该代码在整个帖子中以链接要点的形式提供。

您可以在这里阅读他们的结论以及查看他们的测试结果——https://blog.cloudflare.com/a-tale-of-a-dns-exploit-cve-2015-7547/

CloudFlare 表示，

唯一好的缓解措施是在本地主机上运行 DNS 解析器，攻击者无法导致资源耗尽，或者至少强制执行最小缓存 TTL 以化解等待游戏攻击。

提供以下三个有用的实用程序作为您可以安装和配置的开源解析器：

  1. 未绑定
  2. PowerDNS 递归器
  3. 结点 DNS 解析器

他们还说，

通常来说，一个好的缓解措施是使用本地缓存 DNS 解析器来保护自己，或者至少使用DNS加密隧道。可以说，解析器中也可能存在漏洞，但它只存在于守护进程本身，而不是使用 C 库的所有内容（例如 sudo）。

相关内容