セキュリティ情報を収集することの必要性については，このコラムでも何度か述べてきた。しかし，単に集めるだけでは意味がない。対策に必要な情報を適切に整理する必要がある。そこで今回のコラムでは，セキュリティ情報の整理方法について，最近発見されたOpenSSHのセキュリティ・ホールを例に考えてみたい。
対策に必要な情報をリストアップする
ある程度スキルがある管理者ならば，英文のセキュリティ・ホール情報（アドバイザリ）を一読するだけで，対策に必要な情報を読み取ることができるだろう。しかし，ベンダーなどによってアドバイザリのフォーマットは異なるし，他者へ説明する場合も考慮して，分かりやすい形に整理しておくことが重要だ。また，管理者自身が誤解しないため，あるいは確認するためにも整理しておくことは非常に有用である。
それでは，入手したアドバイザリから読み取るべき情報――すなわち，対策に必要な情報――にはどのようなものがあるだろうか。当然まずチェックすべき情報は，自分が管理しているマシンが影響を受けるかどうかである。つまり，
- （0）セキュリティ・ホールの影響を受けるソフトウエアの種類とバージョン
- （1）対策方法
- （a）ソースへパッチを適用して，適用後に再ビルドする
- （b）実行形式ファイルのパッチを実行する
- （c）ソフトウエア全体を修正されたバージョンに置き換える
- （d）共有ライブラリを置き換える
- （e）設定を変更する
- （f）その他
- （2）対策時のサービス停止の必要性
- （3）対策を施すために必要なサービス停止時間
- （4）対策に必要な費用（パッチや修正版を入手するために必要な費用）
- （5）セキュリティ・ホールを利用する攻撃の可否
- （6）セキュリティ・ホールの概要
- （7）対策の緊急性
- （8）対策したことの確認方法
- （9）対策後の影響
- （10）その他
なお，いくつか上記項目を補足する。まず，対象となるソフトウエアが長時間停止できないサービスを提供している場合には，（3）が重要となってくる。対策後のサービス再起動が，ハングアップ・シグナルを送るだけで済むのなら，サービス停止はほとんど無視できるが，OSの再起動が必要な場合にはもっと長時間になる。
「対策後に検証する必要があるのだが，サービス停止はできるだけ短時間にしたい」――。というような場合には，予備系のシステムを用意してサービスを続行し，その間に本システムに対策を施し，検証後再度切り替えるような必要もあるだろう。
（5）の「セキュリティ・ホールを利用する攻撃の可否」も重要な項目である。（7）「対策の緊急性」に大きく影響するからだ。まず，攻撃の再現性（現実性）が問題となる。あくまでも理論上のものなのか，それとも実際に攻撃が可能なのかどうかで，緊急性は大きく変わってくる。
また，ネットワーク越し（リモート）に攻撃が可能なのか，あるいはマシンにログインする必要があるのか（ローカル）でも，変わってくる。加えて，リモートから攻撃が想定される場合には，ファイアウオールなどのアクセス・コントロールで回避できるかどうかも考慮する必要がある。この場合には，（5）が（1）の「対策方法」にも影響をおよぼすことになる。
（8）の「対策したことの確認方法」も調べておきたい。きちんと確認しておかないと，自分では対策したつもりになっている分，余計危険である。確認方法としては，例えば，バージョン番号やビルド番号による確認が挙げられる。場合によっては，確認するためのツールが公開されているかもしれない。その場合には，ツールの入手方法などについても調べて整理しておきたい。
そして，忘れてはならないのが（9）「対策後の影響」である。対策を施すことで，今まで備えていた機能が使えなくなる場合がある。例えば，サーバー製品である場合には，今まで使用してきたクライアント製品と接続できない場合もありうる。対策後にあわてることがないように，事前に調査しておく必要がある。
対策を施すことで何らかの機能が失われる場合には，対処法（例えば，関連するソフトウエアの設定変更や，新しいソフトの導入など）をあらかじめ用意しておけなければならない。
OpenSSHのセキュリティ・ホール情報を整理する
それでは，今回のOpenSSHのセキュリティ・ホール情報を，上記リストに従って整理してみよう。
OpenSSHは，OpenBSDプロジェクトによって開発および保守されている，SSH（Secure Shell）プロトコルを実装したソフトウエア・パッケージである。このソフトウエアは様々なUNIXで動作するとともに，数少ないフリーのSSHプロトコル実装の一つであることから，広く利用されている。本コラムの読者の中にも，OpenSSHユーザーは多いだろう。
紆余曲折あったものの（詳細については後述），6月27日にはセキュリティ・ホールを修正したバージョン 3.4 が公開された。同時にOpenSSHのサイトには，セキュリティ・ホールに関するアドバイザリが公開された。
加えて，セキュリティ・ホールを発見者した米Internet Security Systems（ISS）や，米CERT/CCからもアドバイザリが公開されている。
それらによれば，対策に必要な情報は以下のように整理できる。。
- （1）対策方法
- ソフトウエア全体を修正されたバージョンに置き換える
- （2）対策時のサービス停止の必要性
- 必要
- （3）対策を施すために必要なサービス停止時間
- 無視できる時間（1分以内）
- （4）対策に必要な費用（パッチや修正版を入手するために必要な費用）
- 無償
- （5）セキュリティ・ホールを利用する攻撃の可否
- リモートからの攻撃が可能
- （6）セキュリティ・ホールの概要
- 【問題1】SKEY あるいは BSD_AUTH コンパイル・オプションが指定されてビルドされたバイナリで，challenge-response認証が有効化されている場合，大量の応答を起こさせることにより，任意のコードを実行させたり，DoS（サービス妨害）を発生させることが可能
- 【問題2】PAM による認証を有効にしている場合，challenge-response認証の設定状態に関係なく，リモートからバッファ・オーバーフローを発生させて，任意のコードを実行させたり，DoS（サービス妨害）を発生させることが可能
- （7）対策の緊急性
- 最優先で対策を施す（IPアドレスなどでsshdへのアクセス・コントロールを施している場合でも，最優先で対応する必要がある）
- （8）対策したことの確認方法
- sshd（TCPポート22番）に接続する。「OpenSSH_3.4」という文字列を含むバナーを返せば，3.4へアップグレードされている
- （9）対策後の影響
- なし。対策（アップグレード）を施しても，従来のSSHクライアントと問題なく接続できる
- （10）その他
- バージョン3.x未満へも影響がおよぶ可能性があるので，影響を受けるバージョンでなくても，3.4へアップグレードが強く推奨されている。一時的な対策として，セキュリティ・ホールに関連するオプションを無効にする方法OpenSSHプロジェクトから公開されているが，この方法は採らず，可能な限りアップグレードする。また，アップグレードに併せて，「Privilege Separated」を有効にすることが推奨される（参考資料，春山征吾氏による参考資料の日本語訳）
以上のように整理すれば，対策の必要性や工数などを，他者に分かりやすく説明できるだろう。また，行うべきことがまとめられているので，実際の作業にも容易に着手できる。
必要に応じてリストを修正
さて，上記リストにより，情報を整理することの意義，メリットを分かっていただけただろうか。しかし，リストを作っただけで満足してはいけない。実際に対策しなければならないことはもちろんだが，リストの作成も1回では済まない場合があるからだ。ベンダーやユーザーによる検証が進むにつれて，当初公開された情報の内容が変更される場合がある。
そのため，一応の整理がついたセキュリティ・ホールに対しても，しばらくは注意する必要がある。そして，変更があった場合には情報の再整理が必要になる。今回例に挙げたOpenSSHのセキュリティ・ホールがまさにそうだった。
OpenSSH 3.3 は米国時間6月21日に公開された。その直後，バージョン 3.3 までに今回のセキュリティ・ホールが見つかり，6月25日に OpenBSDプロジェクトからメーリング・リストや同プロジェクトのサイトなどを通じて，設定変更で対策するようアナウンスされた。
当初，同サイトでは以下のようにアナウンスされた（現在では内容が変更され，バージョン 3.4にアップグレードするよう推奨している）。
006: SECURITY FIX: June 24, 2002
An (as yet) undisclosed bug exists in OpenSSH which a patch is not forthcoming for yet -- no patch exists yet! However, upgrading to OpenSSH 3.3 with the UsePrivilegeSeparation option enabled will block this problem. All users are advised to update immediately, and keep an eye out for a upcoming OpenSSH 3.4 release on Monday containing a real fix.
つまり，当初OpenSSHプロジェクトは，一時的ではあるが「Privilege Separated」という設定の有効化を推奨していた。そのため，この段階でリストを作成した場合には，
- （1）対策方法
- 設定を変更する
なお，Privilege Separatedの有効化は，一時的な対策としてだけではなく，OpenSSHをセキュアに運用するために有効である。筆者としては，リストの（10）「その他」の項に記したように，アップグレードに併せて，この設定を施すことをお勧めする。
◇ ◇ ◇ ◇ ◇ ◇
ただでさえ，セキュリティ情報の収集には手間がかかる。それを改めて整理するのは面倒だと感じる管理者も多いだろう。しかし，確実に対策を施すために，上記のようなリストは非常に有用である。手間を惜しまず実践されることをお勧めしたい。
坂井順行(SAKAI Yoriyuki)
株式会社ラック システムインテグレーション事業本部
sakai@lac.co.jp
IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は，その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え，専門家の立場から解説していただきます。
