インフラセキュリティの処方箋

第13回2015年7月 ~ネットの夏⁠BINDの夏 ~2015年編~

今夏も出ましたBIND脆弱性

2014年7月にも似たような話をさせていただきましたが、2015年7月にも結構盛大なDoS脆弱性が公開されました。昨年~ここまでに出た脆弱性もなかなか味わい深いものが多いのですが、この7月にリリースされた脆弱性CVE-2015-5477は、これまた強烈な脆弱性でした。脆弱性自体は、TKEYレコードの扱いに不備があることに起因してプロセスを異常終了させられるというものです。

この脆弱性を攻略することで、DoSを引き起こすことが可能になるのですが、困ったことに、リリースされた直後に(パッチが非常にeasyだったこともあり)実際の再現コードが出てしまいました。パッチがどれほどeasyだったかは、後述します。

攻撃を避けられない&緩和方法もない脆弱性

今回の脆弱性は、TKEYレコードの処理に不備があるために引き起こされますが、この脆弱性はBINDの設定などで避けられる類いのものではありません。受けたらサービスが停止する、と考えてください。但し、停止したプロセスを自動的に再起動するなどの仕掛けを行えるのであれば、少し間隔は開いてしまうものの、緩和できる可能性はあります。また、ドメイン情報をホストする権威DNSが1つ落とされても、他のDNSが稼働していれば、ドメインの情報を提供するという機能は系としては担保されます。

TKEYレコードとは何か

TKEYレコードとは、DNSクエリを保護するための共有鍵を扱うためのレコードであり、RFC2930で規定されます。ちなみにTKEYは、⁠Transaction KEY⁠の略になります。⁠鍵」と出てくることからDNSSECと何らかの関係があるのかと思われるかもしれませんが、DNSSECが保護するのは、一義にはDNSに登録された情報の正当性です。TKEYが対象とするのはあくまでトランザクションであり、トランザクションの結果得られた情報が正しいものであるかどうかを保証するわけではありません。

修正は非常に明快 ~BIND 9.9.4の場合、パッチは1行~

以下は、CentOSで使われているBIND 9.9.4に対するパッチになります。見ると、変数の初期化漏れに起因している脆弱性ですが、修正箇所が明快すぎ、かつ修正箇所に至るまでの実行経路がわかりやすかったこともあって、今回のような状況を引き起こしたと考えます。

diff -up bind-9.9.4/lib/dns/tkey.c.CVE-2015-5477 bind-9.9.4/lib/dns/tkey.c
--- bind-9.9.4/lib/dns/tkey.c.CVE-2015-5477    2015-07-27 22:36:02.318505839 +0200
+++ bind-9.9.4/lib/dns/tkey.c    2015-07-27 22:36:39.764698712 +0200
@@ -650,6 +650,7 @@ dns_tkey_processquery(dns_message_t *msg
          * Try the answer section, since that's where Win2000
          * puts it.
          */
+        name = NULL;
         if (dns_message_findname(msg, DNS_SECTION_ANSWER, qname,
                      dns_rdatatype_tkey, 0, &name,
                      &tkeyset) != ISC_R_SUCCESS) {

BIND 9.9.4のソースコードは、以下から入手可能です。

おわりに

書いているうちに「これ、DNSの特性を考えると、実はあまり対処を急ぐようなものではない?」とも感じられますが、DNSのメンテナンスを同じようなタイミングで行っており、かつ動作確認等を行ってから入れ替えるという運用だったりすると、どうしても対処は後追いになりがちです。緊急対応が必要な脆弱性が公開された時の対処方針は予め決めておき、かつきちんと機能するように備えておいてください。

おすすめ記事

記事・ニュース一覧