平成10年8月28日 富士通株式会社 |
SSL(Secure Sockets Layer)にセキュリティ・ホールがみつかりました。
このセキュリティ・ホールに対する攻撃方法は、「Million Question攻撃」と呼ばれています。発見者は、米Lucent Technologies社ベル研究所のDaniel Bleichenbacher氏です。当攻撃を防ぐためには、SSLサーバ機能を持つ製品にパッチを当てる必要があります。
この弱点をつく攻撃が実際に行われることは後述の理由から少ないと想定されますが、富士通は出荷済の下記WWWサーバでSSL機能をお使いのお客様に対して、後述の通りパッチを公開する予定です。
SSLを使っているかどうかは、後述の方法で調べることができます。
- InfoProviderPro (WWWサーバ)Windows NT向け V2.0L10以降
Solaris 向け 1.1以降
UXP/DS向け V10L20以降
- InfoProviderPro イントラネットセット
Windows NT向け V2.0L10以降
Solaris 向け 1.1以降
UXP/DS向け V10L20以降
- INTERSTAGE V1.0 (WindowsNT,Solaris,UXP/DS)
- Server Software Pack V1.0 (WindowsNT)
- GS連携イントラネットセット(WindowsNT,UXP/DS)
- SymfoWAREイントラネットセット for WindowsNT V1.2
- インターネット/イントラネット・サーバ・パック (ネットスケープ版)(InfoProviderPro同梱あり)
Solaris運用に用いている環境定義ファイルを調べてください。
環境定義ファイルに 定義名 sslfileが指定されていればSSLを使っています。なければ、使っていません。
環境定義ファイルは、httpdコマンドでInfoProviderProを起動するときに、fオプションで指定するファイルです。fオプションを指定していない場合は、そのコマンドを実行するときのカレントディレクトリにある HTTPD.confというファイルがそれです。UXP/DS
V12L10以降および、INTERSTAGE V10L10に含まれているInfoProviderProについては以下の手順で調べてください。
運用管理Webサーバによるサーバ管理機能で、InfoProvider Pro環境設定画面を出します。
存在する環境名ごとに、更新を選んで内容を調べます。SSL情報設定をクリックして、SSL情報設定画面に行き、SSLを使っているかどうかのチェックボックスを見て判断できます。V10L20およびV10L21については以下の手順で調べてください(これ以前の版にはSSL機能はありません)。
運用管理Webサーバによるサーバ管理機能で、InfoProvider Pro環境設定画面を出します。
証明書定義設定をクリックして、証明書定義設定画面に行き、サイト証明書ファイル名、サイト秘密鍵ファイル名、サイト秘密鍵ファイルパスワード、発行局証明書ファイル名が設定されていればSSLを使っています。Windows NT
INTERSTAGEに含まれている InfoProviderProの場合は、上記のSolaris版と同様に調べてください。ただし、調べる対象の環境定義ファイルは、自動起動を用いている場合は、set_startup -p コマンドで表示されるものです。直接httpdコマンドを用いて起動している場合は、その fオプションで指定したファイルです。
INTERSTAGEと関係なくご購入いただいたInfoProviderProの場合は、InfoProviderProのアイコンからメニューを起動し、オプションの環境設定を起動します。一覧表示される環境設定ファイルごとにそれらをダブルクリックして設定画面を開き、SSLのタブを選びます。そこでSSLのバージョンが設定されていれば、SSLを使っています。
InfoProviderPro(WWWサーバ)のパッチの公開時期は下記の表の通りです。
パッチが必要なお客様は、下記の表の応急修正番号をお控えの上、当社担当営業またはご購入いただいた販売会社にお問い合わせください。
OS VL 公開時期 応急修正番号 WindowsNT V2.0L10 1998年09月中(予定) TP00662 Solaris 2.0 1998年09月04日 910037-01 UXP/DS V12L10 検討中
InfoProviderProを内蔵する製品についても、上記に準じます。なお、今後出荷するInfoProviderPro、及び新規にSSLサーバ機能を追加する富士通製品(InfoCA, InfoDirectory, PKI Manager,System Walkerなど)では、すべて当攻撃の対応を行います。
このセキュリティホールをつく攻撃の対象は、SSLを使って行われた1回のセションです。SSLにとってのセションの期間はサーバ及びブラウザの実装によって様々です。
webのページを一つ進むとか、アンケートや買い物の注文画面を1画面送るような短期間の場合から、セキュアなwebページをアクセスし始めてからブラウザを終了するまでのような長期間の場合まであります。
当社の実装では、後者のような長期間になるのは、サーバ側でSSLv3.0を使用してかつブラウザ側に証明書を登録した場合のみとなります。この1回のセションを攻撃者は監視してやり取りを記録します。
その後、同じサーバに対してSSLのセションを張ることを多数回試みます。このとき、Daniel Bleichenbacher氏の方法を使うと、記録したセションで暗号化に使われたセション鍵を割り出すことが、行き当たりばったりに攻撃するのに比べると格段に容易にできるのです。しかし、攻撃が成功するまで平均して100万回レベルの試行回数が必要なことが分かっており、それで判明するのは、ただ1つのセション鍵の値ですから、結果として解読されるのはそのセションでやり取りされた秘密データに限定されます。
このような特徴をもつため、攻撃が1回成功しても、その対象となった1セション以外には被害はひろがりません。
つまり、攻撃者にとって努力の割には得られるものが少ないことが多いのです。
さらに 多数回の試みの形跡がサーバのログに特徴的に現れるので、サーバの運用者がログファイルに注意する、あるいは、CPU負荷を定期的に監視するなどしていれば、運用形態にもよりますが、成功するまでに攻撃を検出も可能な場合があります。
攻撃の現場を見つけられやすいことも攻撃者にとっては都合が悪い点です。提供する修正は、Daniel Bleichenbacher氏の方法を使っても、実用時間内にセション鍵を見つけることができないようにするものです。
修正は、攻撃を受ける側のサーバ側に適用します。クライアント(ブラウザ等)には修正は不要です。
以上