web-dev-qa-db-ja.com

getaddrinfo（）のGlibcバグ軽減

DNS解決のためのgetaddrinfo（）呼び出しを含む今日のglibcの exploit に出くわしました。インターネットに面した2つのBind9ボックスでUbuntu12.04を実行しています。このエクスプロイトを完全に理解しているかどうかはわかりませんが、悪意のあるDNSサーバーからの大量の応答が原因のようです。緩和策の1つは、「512バイトを超えるUDP DNSパケットをドロップするファイアウォール」であるため、DNSサーバーでnetfilterを構成して、またはからの512バイトを超えるUDPをドロップします。に行く、ポート53：-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で投げられた512を超えるUDPパケットをブロックします。

応答ごとに更新：-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/namesed.conf.options

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

UPDATE 2：以下の atdre で指摘されているように、Cloudflareは上記の手法を試しましたが、ペイロード全体を転送できませんでしたが、メモリ破損はまだ可能性がありました。 Unboundを調べてみようと思います。

linuxsecuritybinddns-hosting
4
Server Fault

ローカルでバインドを実行している場合、これによりテストが行​​われます。

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 ;
};

名前付きファイル内

ここで説明されているように： https://labs.ripe.net/Members/anandb/content-testing-your-resolver-dns-reply-size-issues 。

私はこれを他の緩和策と組み合わせて使用​​します。

3
birdwes

一方512バイトを超えるUDP DNSパケットをドロップするファイアウォール。はエクスプロイトを軽減します（特にUDPを介して、TCP攻撃ベクトルである）これも正しい動作ではなく、代わりに他の機能を破壊します。

EDNS0の導入以来、DNS仕様にはそのような制限はなく、パケットをドロップするだけで有効なトラフィックが破損する可能性があります。

Birdwesが提案するのは、応答サイズをクライアントに制限するようにリゾルバーネームサーバーを構成することで、クライアントは少なくとも、沈黙と最終的にはタイムアウトではなく、仕様に従って適切に通知（応答の切り捨て）されるため、より良い方法ですが、適切な解決策は、パッチを適用したglibcをインストールすることです（ここで何かが間違っていて、サイズは間違っていません）。

6
Håkan Lindqvist

少しテストした後、CloudFlareは、DNSパケットの応答サイズを制限し、EDNS0サポートをオフにしても、CVE-2015-7547は修正されないと判断しました。投稿全体でリンクされた要点として利用できる作成者のPoCコードを使用して、自分でテストできます。

あなたは彼らの結論について読むことができ、そして彼らのテストの結果をここで見ることができます-- https://blog.cloudflare.com/a-tale-of-a-dns-exploit-cve-2015-7547/

CloudFlareは言う、

唯一の適切な緩和策は、攻撃者がリソースの枯渇を引き起こすことができないローカルホストでDNSリゾルバーを実行するか、少なくとも待機中のゲーム攻撃を阻止するために最小キャッシュTTLを強制することです。

インストールおよび構成できるオープンソースリゾルバーとして、次の3つの便利なユーティリティを提供します。

  1. アンバウンド
  2. PowerDNS Recursor
  3. ノットDNSリゾルバー

彼らはまた言い続けます、

一般的に適切な緩和策は、ローカルキャッシングDNSリゾルバー、または少なくとも DNSCrypt トンネルで身を守ることです。おそらく、リゾルバーにも脆弱性がある可能性がありますが、それはデーモン自体に含まれており、Cライブラリを使用するすべてのもの（Sudoなど）には含まれていません。

2
atdre