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

第2回ネットの夏、BIND・OpenSSL脆弱性の

ネットの夏、BIND脆弱性の夏~夏のBIND脆弱性祭り

7月になって、暑さも本格化してきてますが、皆さまはいかがお過ごしでしょうか? 今回はまず、DNSサーバ実装として定番となっているBINDの脆弱性の話について触れてみます。

この数年、日本の夏はBINDにとって厳しい季節

別にこれは、日本の夏の高温多湿がBINDにとって悪いと言ってるわけではありません。この数年、6~7月にかけて、BINDの深刻な脆弱性が集中して公開されている状況を指してこのように述べています。

BIND関連の脆弱性情報は、以下のURLから取得できます。

ISCのページからは、BINDの脆弱性の英語版(オリジナル)と日本語訳(翻訳)を参照可能ですが、少し時系列を追いづらいので、JPRSの情報を見てみることにします。

2009年~2013年の5年間を見ると、月別の脆弱性情報公開件数が最も多いのが7件(7月⁠⁠、以下5件(12月⁠⁠、4件(6月⁠⁠、2件(1月⁠⁠、1件(2月、3月、5月、9月、10月、11月)と続きます。2009年~2013年の脆弱性公開件数が24件ありますが、6月と7月の合計でも11件と、半数近くを占めており、それに12月の公開件数を合計すると16件と、全体の3分の2を占めています。

DoS攻撃が多いのが不幸中の幸い

ここまでは、6月~7月で脆弱性情報が多く公開されているということを示しましたが、それでは6月~7月に公開される脆弱性は、どのようなものが多いのか? というのを見てみましょう。

多くのものは、題名を見るとサービス停止もしくはメモリリークとわかる書き方がされています。2010年7月16日に公開された脆弱性については、少し題名がわかりにくいですが、内容を見ると最終的にはDoSを引き起こすことがわかります。

他の月の脆弱性を見ると、⁠意図しないアクセス許可」というものが含まれることもありますが、多くのものはサービス停止に関連したものであることがわかります。

DNSには、機構的にDoS以外の脆弱な面もあることを知ろう

ここまでに挙げて来たのは、BINDの実装由来の脆弱性の話ですが、この数年はキャッシュポイゾニングの脆弱性が指摘され続けており、今年の4月ころまでに鈴木常彦氏(中京大学教授)と前野利紀氏によるキャッシュポイゾニング関連の脆弱性(それもDNS関連のRFCレベルで修正される必要があるもの)が指摘されています。

キャッシュサーバ側での対処であるSource Port Randomizationをはじめとする対策を施すことで、危険性を緩和することが可能である旨も上記URL中で述べられています(あくまで緩和であり、根本対処でないことに注意⁠⁠。

ゾーンサーバ(ゾーン情報を提供するDNSサーバ)側での対処も書かれていますが、この対処を行えるのはあくまでドメイン(もしくはサブドメイン)を管理する側であり、DNSによる名前解決の結果を利用するエンドユーザ側にはムリな対処です。ユーザ側もしくはユーザを抱えるシステム管理者側で出来る対処は、おもにキャッシュサーバ側の対処であると考えるのが自然です。自前での対処が困難な場合は、自前でDNSキャッシュサーバを運用するのではなく、ISPなどサービス提供者が用意するDNSキャッシュサーバを直接利用するというのも視野に入れたほうが良いでしょう。

参考:2009年~2014年のBIND脆弱性情報

以下は、2009年から2014年にJPRSから公開された脆弱性情報のうち、BINDに関連したもののみを紹介します。

2014年のBIND脆弱性情報

まだ今年も途中ですが、5月と6月に脆弱性が公開されています。

  • 2014-06-12 ⁠緊急)BIND 9.10.xの脆弱性(DNSサービスの停止)について(2014年6月12日公開)
  • 2014-05-09 ⁠緊急)BIND 9.10.0の脆弱性(DNSサービスの停止)について(2014年5月9日公開)
  • 2014-01-14 ⁠緊急)BIND 9.xの脆弱性(DNSサービスの停止)について(2014年1月14日公開)

2013年のBIND脆弱性情報

2013年は、1月、3月、6月、7月、11月に1件ずつ脆弱性が公開されています。

  • 2013-11-07 BIND 9.xの脆弱性(サービス提供者が意図しないアクセスの許可)について(2013年11月7日公開)
  • 2013-07-27 ⁠緊急)BIND 9.xの脆弱性(DNSサービスの停止)について(2013年7月27日公開)
  • 2013-06-05 ⁠緊急)BIND 9.xの脆弱性(DNSサービスの停止)について(2013年6月5日公開)
  • 2013-03-27 ⁠緊急)BIND 9.xの致命的な脆弱性(過度のメモリ消費)について(2013年3月27日公開)
  • 2013-01-25 BIND 9.8.x/9.9.xにおけるDNS64/RPZの実装上のバグによるnamedのサービス停止について(2013年1月25日公開⁠

2012年のBIND脆弱性情報

2012年は7月に2件、6月、9月、10月、12月に1件ずつ脆弱性が公開されています。

  • 2012-12-05 BIND 9.8.x/9.9.xにおけるDNS64の実装上のバグによるnamedのサービス停止について(2012年12月5日公開)
  • 2012-10-10 ⁠緊急)BIND 9.xの脆弱性(サービス停止)について(2012年10月10日公開)
  • 2012-09-13 ⁠緊急)BIND 9.xの脆弱性(サービス停止)について
  • 2012-07-25 BIND 9.9.xの大量のTCP問い合わせ受信時におけるメモリリーク発生について
  • 2012-07-25 BIND 9.xの大量のDNSSEC検証要求受信時におけるサービス停止について
  • 2012-06-05 ⁠緊急)BIND 9.xの脆弱性(サービス停止を含む)について

2011年のBIND脆弱性情報

2011年は、6月、7月、12月に2件、2月、5月に1件の脆弱性が公開されています。

  • 2011-12-07 ⁠緊急)BIND 9.xのキャッシュDNSサーバー機能の実装上の問題によるnamedのサービス停止について
  • 2011-12-05 BIND 9.8.x/9.9.xにおけるDNS64の実装上のバグによるnamedのサービス停止について(2012年12月5日公開)
  • 2011-07-08 ⁠緊急)BIND 9.xの脆弱性を利用したサービス不能(DoS)攻撃について
  • 2011-07-08 BIND 9.8.xのResponse Policy Zones(RPZ)機能の実装上のバグによるnamedのサービス停止について
  • 2011-06-01 ⁠緊急)BIND 9.xのネガティブキャッシュ機能の実装上のバグによるnamedのサービス停止について
  • 2011-05-09 BIND 9.8.0のResponse Policy Zones(RPZ)機能の脆弱性を利用したサービス不能(DoS)攻撃について
  • 2011-02-23 ⁠緊急)BIND 9.7.xの脆弱性を利用したサービス不能(DoS)攻撃について

2010年のBIND脆弱性情報

2010年は、12月に2件、1月、7月に1件の脆弱性が公開されています。

  • 2010-12-15 ⁠緊急)BIND 9の否定応答受信時のRRSIGレコードの取り扱いの不具合を利用したDoS攻撃について
  • 2010-12-02 BIND 9のallow-queryによるアクセス制限の不具合について
  • 2010-07-16 ⁠緊急)BIND 9.7.1/9.7.1-P1におけるRRSIGレコード処理の不具合について
  • 2010-01-20 BIND 9の脆弱性を利用したキャッシュポイズニング攻撃について(第3版)

2009年のBIND脆弱性情報

2009年は、7月に1件の脆弱性情報が公開されています。

  • 2009-07-29 ⁠緊急)BIND 9のDynamic Update機能の脆弱性を利用したDoS攻撃について

4月~6月のOpenSSL脆弱性祭り~何がどの程度危険なの?

ほぼ今さら感があるOpenSSL脆弱性祭りですが、4月のHeartbleed脆弱性と6月のCCS Injectionという大物脆弱性の2つに共通するのは、作り込まれた脆弱性が「なにこれ」というくらいに単純なミスで引き起こされているようにしか見えないことです(脆弱性全般そうとも言える気はしますが⁠⁠。

HeartbleedはDeNAの開発者blogに、CCS Injectionは、発見者であるレピダムの菊池氏による説明に詳しく示されています。

対処については、どちらも修正パッチを適用することが必要なのですが、Heartbleedについてはそれだけでは不十分で、⁠SSLの秘密鍵漏えい」という危険性もあります。漏えいした秘密鍵では、通信そのものの秘匿が困難になることもあり、脆弱性を修正した後に、SSLで用いる秘密鍵の入替えも必要になってきます。

脆弱性によって引き起こされる事象によっては、修正パッチを適用するだけでは不十分であると考えてください。

また、OpenSSLそのものの課題としては、LibreSSL開発プロジェクトを開始したBob Beck氏によるBSDCan2014での発表では、OpenSSLが抱える問題の指摘がなされるとともに、現状のOpenSSLとともに歩むことが困難であるということ(だからOpenSSLからLibreSSLプロジェクトをfork(開始)したということ)を述べています。

おすすめ記事

記事・ニュース一覧