米CERT/CCは米国時間11月14日，代表的なDNSサーバー・ソフト・パッケージ「BIND」 のセキュリティ・ホールに関するアドバイザリを公開した。筆者が所属するラックでは日本語版を公開しているものの，アドバイザリだけでは分かりにくい点が少なくない。そこで今回のコラムでは，このセキュリティ・ホールを詳細に解説したい。既に対策済みの管理者も改めて確認していただきたい。併せて対策方法も解説するので，まだ対策をしていない管理者はこのコラムを参考にして早急に対策を施してほしい。
任意のコードを実行されるセキュリティ・ホール
今回警告されたセキュリティ・ホールは4種類である。まずは，それぞれを順に解説し，その後対策方法について説明する。
第1のセキュリティ・ホールは，BINDに含まれる「named」のバッファ・オーバーフローのぜい弱性である。キャッシュさせられたある特定の「SIG Resource Record （RR: 資源レコード）」を named が参照すると，バッファ・オーバーフローが発生し，DNSサーバー上で任意のコードを実行される恐れがある。これは，再帰的問い合わせに応答する機能（recursion）を有効にしている場合に発生する。
悪用のシナリオは次のようになる。攻撃者は，再帰的問い合わせが有効となっている“標的”DNS サーバーに問い合わせを行い，あらかじめ侵入している別のDNS サーバーから権威つき応答（authoritative answer）を取得させ，バッファ・オーバーフローを発生させるような“異常な”SIG RR をキャッシュさせる。
そして，攻撃者が再度標的DNS サーバーにこのキャッシュを参照させるような問い合わせを行うと，バッファ・オーバーフローが発生する。バッファ・オーバーフローを発生させることにより，攻撃者は任意のコードをnamed の権限（通常はroot）で実行させることが可能になる。
このセキュリティ・ホールの影響を受けるのは，BIND のバージョン 4.9.5 から 4.9.10，8.1，8.2 から 8.2.6，8.3.0 から 8.3.3。
DoS攻撃を許すセキュリティ・ホール
第2のセキュリティ・ホールは，ある特定の問い合わせをnamedが適切に処理できないことに起因する。具体的には，オプション扱いの RR に対するリクエストを付け加えた，非常に長い UDP ペイロードを含む問い合わせを適切に処理できない場合がある。
このセキュリティ・ホールを悪用すれば，攻撃者はDNSサーバーをサービス不能（DoS）状態にすることが可能になる。例えば，実在するドメイン内の，実在しないサブ・ドメインに対するリクエストを送信すれば，標的DNSサーバーをDoS状態にできる可能性がある。
実際，筆者が所属するラックの「LAC SNS Team」は，このセキュリティ・ホールを利用してBINDを停止できることを確認している。第1のセキュリティ・ホール同様，このセキュリティ・ホールも再帰的問い合わせを有効にしている DNS サーバーが影響を受ける。ただし，影響を受けるバージョンは8.3.0 から 8.3.3 まで。
第3のセキュリティ・ホールは，攻撃者にDNSサーバーをクラッシュさせられる恐れがあるセキュリティ・ホールである。攻撃のシナリオは第1のセキュリティ・ホールの場合とほぼ同じである。攻撃者は，標的とは異なる，権威ある（authoritative）DNS サーバーを乗っ取っている必要がある。そこから標的DNSサーバーに対して，ある特定のSIG RR を含む DNS 情報をキャッシュさせることで，標的DNS サーバーをクラッシュさせることが可能となる。
影響を受けるBINDのバージョンは，8.2 から 8.2.6 および 8.3.0 から 8.3.3 まで。
リゾルバ・ライブラリにもセキュリティ・ホール
以上3つのセキュリティ・ホールは，namedに存在する。しかし，第4のセキュリティ・ホールは，DNSスタブ・リゾルバ・ライブラリに存在する。
DNSリゾルバ・ライブラリのセキュリティ・ホールに関するアドバイザリは，以前も「CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries」（ラックによる日本語版も公開されている) として公開されている。今回報告されたセキュリティ・ホールは，「CA-2002-19」で報告されたものとは異なるので注意してほしい。
今回報告されたセキュリティ・ホールは，DNSスタブ・リゾルバ・ライブラリが，DNSレスポンスを受け取る際に十分な境界チェックを行わないことが原因である。DNSスタブ・リゾルバ・ライブラリがある特定のレスポンスを受け取るとバッファ・オーバーフローが発生し，任意のコードを実行されてしまう恐れがある。影響を受けるのは，BIND 4.9.2 から 4.9.10 に同梱されている DNS スタブ・リゾルバ・ライブラリである。
第4のセキュリティ・ホールはライブラリのセキュリティ・ホールであるため，あらゆるアプリケーションに影響を与える恐れがあるので注意が必要だ。特に，問題があるライブラリを静的にリンクしているアプリケーションについては再コンパイルする必要がある（詳細は後述）。
基本的な対策はアップグレード，キャッシュ汚染にも注意
第1から第3までのセキュリティ・ホールは，現時点における BIND 9.x の最新版「BIND 9.2.1」にアップグレードすることで解消できる。今回のセキュリティ・ホールを解消した「BIND 8.3.4」および「BIND 8.2.7」へアップグレードすることでも解消することができる。
もちろん，「djbdns」といったBIND以外のDNSサーバー・ソフトへ移行することも，セキュリティ・ホールの影響を回避する方法の一つである。
また，CERT/CC のアドバイザリでは，再帰的問い合わせを無効にすることを回避策として挙げている。再帰的問い合わせは BIND ではデフォルトで有効になっている。
今回警告された問題以外にも，再帰的問い合わせを有効にしているBIND 4.x および 8.x では，偽の DNS 情報を含んだキャッシュを作成してしまう問題（これを，“キャッシュ汚染”あるいは“cache-poisoning”などと呼ぶ）が指摘されている。
今回報告されたセキュリティ・ホールだけではなく，キャッシュ汚染の問題を解消するためにも，再帰的問い合わせを受け付ける必要がない DNS サーバーでは，再帰的問い合わせを無効にしておきたい。もちろん，アップグレードなどの対策を施しておくことも不可欠である。なお，再帰的問い合わせの無効化については，「Securing an Internet Name Server」の「Protecting against cache-poisoning」の項を参照してほしい。
再帰的問い合わせを無効にできないDNS サーバーでは，BIND 9.2.1 へのアップグレードや，別の DNS サーバー・プログラムへの移行などでキャッシュ汚染に対処することになる。
ちなみに，キャッシュ汚染の問題は BIND に限らない。CERT/CC の「Vulnerability Note」によると，例えばMicrosoft DNS Server でも発生する。Microsoft DNS Server において再帰的問い合わせを無効にする方法は，「[NT]Microsoft DNS Server のレジストリ設定」や「(Windows 2000) DNS サーバーで再帰を無効にする」に詳しい。
BIND 4.9.2 から 4.9.10 に同梱されている DNS スタブ・リゾルバ・ライブラリが影響を受ける第4のセキュリティ・ホールについては，「BIND 4.9.11」へアップグレードすることやパッチを適用することが対策となる。ただし，単にアップグレードするだけでは不十分である。ライブラリを静的にリンクしているアプリケーションを再コンパイルする必要がある。
既に公開されていた“第2のセキュリティ・ホール”
なお余談ではあるが，CERT/CC のアドバイザリで警告された4種類のセキュリティ・ホールのうち1つは，このアドバイザリが公開される前に明らかになっていた。筆者が確認したところによると，日本時間2002年10月25日の時点で，米Internet Security Systems（ISS）が第2のセキュリティ・ホールを「ISC BIND OPT resource record (RR) denial of service」として公開していた。
ただしこの時点では，BINDをメンテナンスしているInternet Software Consortium（ISC）の対応状況が不明であったため判断が難しかった。しかしISCのその後の対応により，この情報が正確であることが明らかとなった。
新井悠 (ARAI Yuu)
株式会社ラック コンピュータセキュリティ研究所
y.arai@lac.co.jp
IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は，その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え，専門家の立場から解説していただきます。
