メディア

オープンソース流「広報戦略“虎の巻”」：オープンソースソフトウェアの育て方（4/4 ページ）

» 2009年10月29日 08時00分公開

[Karl Fogel， ]

事前通知

　セキュリティ対策チーム（セキュリティメーリングリストのメンバー、あるいはそのセキュリティ問題の対応担当者）が修正を完了したら、次はそれをどのように公表するのかを判断する必要があります。

　単に修正をリポジトリにコミットするとか全世界に公表するとかだと、そのソフトウェアを使用している人たちは事実上即時のアップグレードを迫られることになってしまいます。さもないと、攻撃を受ける危険性が生じるわけですから。従って、ある種の重要なユーザー向けには事前通知をしておく方が適切なこともあります。

　いわゆるクライアント／サーバ型のソフトウェアなどでは特にこれが重要です。有名なサーバが、一時的にでも攻撃の対象となってしまう可能性があるからです。これらのサーバの管理者にとっては、アップグレードを行うためには1日から2日の時間が必要となるでしょう。脆弱性が一般に公開される前にそのくらいの猶予があれば、サーバの管理者はありがたいと思うことでしょう。

　事前通知とは、単に一般公開前にそれらの管理者向けにメールを送信することを指します。通知メールでは、脆弱性の内容とその対処方法を説明しておくようにします。事前通知の送信先は、その情報を適切に扱ってくれると信頼できる相手に限定しなければなりません。つまり、事前通知を受け取る資格があるのは、次の2つの条件を満たす相手だけだということです。まず、攻撃を受けると深刻な問題となるような巨大で重要なサーバを運営しているということ。さらに、一般公開の前にその問題をペラペラしゃべってしまうような口の軽い人ではないということ。

　事前通知のメールは、それぞれの相手に個別に（一度に一通ずつ）送信します。全員に一括送信などしてはいけません。そんなことをすれば、それを受け取った人たちに「わたしのほかにどんな相手に送っているのか」を知られてしまいます。これが何を意味するのか。それを受け取った人は「（わたし以外の）ほかのメンバーのサーバにも同じセキュリティホールがある」ということを知ってしまうことになります。全員をブラインドカーボンコピー（BCC）で指定すればいいという問題でもありません。受け取り先が使用しているスパムフィルタの設定によっては、BCCで送信されたメールをブロックしたり優先度を下げたりするようになっていることもあるからです（最近のスパムには、BCCを使用して送られてくるものが多いのです）。

　事前通知メールの例を、ここに示します。

From: あなたの名前

To: admin@large-famous-server.com

Reply-to: あなたの名前（セキュリティメーリングリストのアドレスではありません）

Subject: [機密] セキュリティ脆弱性の通知

このメールは、Scanley サーバにおけるセキュリティ警告に関する極秘の事前

通知です。

このメールの内容は、決して他人に転送しないでください。一般向けには 5 月

19 日に公表する予定です。それまではこの情報を口外しないようお願いいたし

ます。

あなたにこのお知らせを送信した理由は、（恐らく）あなたが Scanley サー

バをご利用いただいており、5 月 19 日にセキュリティホールを公表する前に

パッチを適用したいであろうと考えられるからです。

参照:

=====

CAN-2004-1771: Scanley stack overflow in queries

脆弱性:

=======

サーバのロケールの設定が正しくない場合に、クライアントから不正な

クエリを送信するとサーバ上で任意のコマンドを実行できるようになります。

重大度:

=======

非常に深刻。サーバ上で任意のコードの実行を許してしまいます。

回避方法:

=========

scanley.conf で 'natural-language-processing' オプションを 'off'

に設定することで、この脆弱性を回避可能です。

パッチ:

=======

以下のパッチは Scanley 3.0、3.1 および 3.2 に適用可能です。

新しい公開リリース（Scanley 3.2.1）が 5 月 19 日の直前に公開されます。

つまり、この脆弱性を公表するのと同時に公開するということです。以下の

パッチを適用するか、あるいは新しいリリースが発表されるのをお待ちくだ

さい。3.2 と 3.2.1 の違いは、以下のパッチのみです。

[...ここにパッチを示します...]

　CAN番号を取得している場合は、それを事前通知に含めるようにしましょう（先ほどの例で示したようにします）。まだ情報は公開されておらずMITREのページには何も掲載されていませんが、それでも含める価値があります。CAN番号を示すことで、それを受け取った相手は「この通知で知ったバグと後日正式に公開されるバグが確かに同じものである」ということを確認できます。正式にバグが公開されたときに、余計な心配をせずにすむというわけです。まさにこれこそが、CAN／CVE番号の重要なところです。

修正を一般に公開する

　セキュリティバグへの対応で最後に行うのが、修正内容を一般に公開することです。1つの包括的なアナウンスで、以下の内容を説明しなければなりません。まずその問題の内容、そしてCAN／CVE番号を取得していればその番号、当面の回避策と本質的な修正方法などを示します。

　「修正」は、通常はそのソフトウェアの最新バージョンへのアップデートとなります。しかし、ソースコード形式で実行されるソフトウェアなどでは、パッチの適用をもって「修正」とすることもあります。新しいリリースを作成した場合は、それが通常のリリースとは異なりセキュリティパッチの適用によるものであることを明示しておく必要があります。そうしておけば、保守的な管理者であっても副作用を気にせずにアップグレードできるようになります。当然、今回のセキュリティ修正は将来のリリースにも含まれているでしょうから、将来のアップグレードの際にも心配せずにすみます（リリース手続きの詳細については、章7.パッケージの作成、リリース、日々の開発のセキュリティリリース項で説明します）。

　セキュリティ対応の修正で新バージョンをリリースするか否かにかかわらず、通常の新バージョンのリリースと同程度の優先度でアナウンスを行うようにします。つまり、そのプロジェクトのannounceメーリングリストにメールを送ったりプレスリリースを作成したりFreshmeatのエントリを更新したりといったことです。

　そのプロジェクトの評判を気にしてセキュリティバグの存在を甘く見るなんてことは論外ですが、セキュリティに関するアナウンスの影響と実際の問題の重大度との兼ね合いには注意しましょう。そのセキュリティホールが単にささいな情報が漏えいするというだけのものであってコンピュータ全体が乗っ取られてしまうほどのものではないという場合は、あまり大騒ぎしない方がいいこともあります。場合によってはannounceメーリングリストへの投稿も控えるということもありえます。ささいなことで毎回大騒ぎしていると、ユーザーはどう思うでしょう？　実際にはそれほどではないのに「このソフトウェアはあまり安全ではない」と思われてしまうかもしれません。また、本当に深刻な問題が発生したときにそれをアナウンスしても、「またいつものやつだろう」と無視されてしまう可能性もあります。

　重要度の判断方法については、Terminologyに素晴らしい入門文書があるので、ぜひご覧ください。

　セキュリティ問題の対処方法がよく分からない場合は、経験がありそうな人を探して相談しましょう。脆弱性の評価やその処理の技術は、経験を積まないとなかなか得られないもので、最初のうちは失敗することが多いものです。