#931 ISC BIND に複数の脆弱性、バージョンアップを強く推奨

今回取り上げるのは、広く使われているDNSサーバソフトウェアであるISC BINDに複数の脆弱性が見つかり、開発元がアップデートを公開したというニュースです。リスナーの皆さんには脆弱性がどういった影響を及ぼすのか、どのバージョンが危険なのか、そして実務としてどのように対応すべきかを具体的にお伝えします。本放送を聞けば、脆弱性の技術的なポイントと優先的な対処手順が理解でき、現場での判断に役立てていただけます。

今回の報告は三つの主要な脆弱性に関するものです。ひとつめは特定条件下で応答に含まれるリソースレコードを誤って受け入れてしまう脆弱性で、結果として偽のリソースレコードがキャッシュされる恐れがあります。ふたつめは内部で使われる疑似乱数生成器の弱さにより送信元ポートとクエリIDが予測されやすくなり、これもキャッシュポイズニングの成功率を高めます。みっつめは細工されたDNSKEYレコードを処理することでCPUリソースが枯渇しサービスが停止する可能性がある脆弱性です。影響範囲はBINDの複数バージョンに及び、開発元はBIND 9.18.41、9.20.15、9.21.14などへの更新を推奨しています。短期的には速やかなバージョン適用が第一優先で、確認と監視を並行して行うことが重要です。

ISC BINDはドメインネームシステムの代表的な実装であり、名前解決を行うためのソフトウェアです。世界中のDNSサーバに採用例が多く、ルートサーバや企業のオンプレミス環境、クラウド上のDNSサービスの基盤として使われていることが多い点が特徴です。そのため脆弱性が見つかると広範囲に影響しやすく、運用側はソフトウェアのバージョン管理やセキュリティパッチ適用を常に意識する必要があります。DNSはネットワークの基盤なので可用性と信頼性の観点から厳格な対策が求められます。

CVE-2025-40778は応答に含まれる不正なリソースレコードを受け入れてしまう処理の問題が原因で、外部から受け取った偽情報をそのままキャッシュに入れてしまう挙動が問題です。CVE-2025-40780は内部の疑似乱数生成器が弱く送信元ポートやクエリIDが予測可能になる点が問題で、攻撃者が正しい組み合わせを予測して偽の応答をなりすませる確率が上がります。どちらも結果として信頼できない回答がキャッシュされるため、ユーザが偽サイトへ誘導されるリスクがあります。根本は応答の検証とランダム性の強化不足にあります。

まずは開発元が公開した対応版、具体的にはBIND 9.18.41、9.20.15、9.21.14などへのアップデートを優先してください。パッケージ管理システムを使う環境では公式リポジトリか配布元のパッケージを使用して更新し、ソースから導入している場合は公式のリリースノートに従って再ビルドと再配置を行います。適用後はnamedのバージョン表示コマンドやプロセス情報でバージョンを確認し、実際の挙動変化はDNSクエリに対する応答の検証とログ監視で確認します。更新後も監査ログや監視アラートをしばらく強化して異常を検出できるようにしてください。

すぐにアップデートできない場合は外部からの直接的なアクセスを制限することや問い合わせポリシーを厳しくすることが有効です。キャッシュポイズニング対策としてはクエリのソースポートランダム化やDNSトラフィックのフィルタリングを強化し、DNSSECを可能な限り導入して署名検証を行うことも効果的です。また異常なトラフィックやCPU負荷の監視閾値を下げてアラートを出す設定に変更し、侵害の兆候を早期に検知できるようにしてください。臨時対応としては脆弱なインスタンスを内部ネットワークに隔離することも検討してください。

長期的にはソフトウェアのライフサイクル管理を徹底することが重要です。具体的には定期的なバージョン棚卸しと脆弱性情報の監視、構成管理と自動化されたアップデート手順の整備が必要です。運用チームとセキュリティチームが連携してインシデント対応計画を用意し、テスト環境でパッチ適用の影響を検証してから本番に展開するフローを確立してください。さらにDNSSECや冗長化、監視の強化を組み合わせることで単一障害点とリスクの蓄積を防ぐことができます。