オープンソース流「広報戦略“虎の巻”」:オープンソースソフトウェアの育て方(4/4 ページ)
フリーソフトウェアの世界では、内部での議論と一般向けのアナウンスの間に明確な違いはありません。このため、正しい方法で情報の報道価値を示す必要があります。とりわけセキュリティ問題については、開放性と秘密主義の対立に折り合いをつける方針が存在しますので、これらをまとめて紹介します。
- 事前通知
セキュリティ対策チーム(セキュリティメーリングリストのメンバー、あるいはそのセキュリティ問題の対応担当者)が修正を完了したら、次はそれをどのように公表するのかを判断する必要があります。
単に修正をリポジトリにコミットするとか全世界に公表するとかだと、そのソフトウェアを使用している人たちは事実上即時のアップグレードを迫られることになってしまいます。さもないと、攻撃を受ける危険性が生じるわけですから。従って、ある種の重要なユーザー向けには事前通知をしておく方が適切なこともあります。
いわゆるクライアント/サーバ型のソフトウェアなどでは特にこれが重要です。有名なサーバが、一時的にでも攻撃の対象となってしまう可能性があるからです。これらのサーバの管理者にとっては、アップグレードを行うためには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に素晴らしい入門文書があるので、ぜひご覧ください。
セキュリティ問題の対処方法がよく分からない場合は、経験がありそうな人を探して相談しましょう。脆弱性の評価やその処理の技術は、経験を積まないとなかなか得られないもので、最初のうちは失敗することが多いものです。
著者:Fogel Karl
翻訳者:高木 正弘
翻訳者:Takaoka Yoshinari(a.k.a mumumu)
製作著作 © 2005, 2006, 2007, 2008, 2009 Karl Fogel, 高木正弘, Yoshinari Takaoka(a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)
よいフリーソフトウェアを作ることは本質的に価値のある目標です。その方法を模索している読者の皆さんが、本連載「オープンソースソフトウェアの育て方」で何かのヒントを得てくだされば幸いです。
関連記事
- バグ追跡システムで議論を始めてしまう人たち
バグ追跡システムを積極的に活用しているプロジェクトでは、バグ追跡システムで議論そのものを進めてしまうようになる危険が常にあります。しかし、バグ追跡システムは議論に適していない場所です。ここでは、適切な選択ができるように一般的な原則を中心に紹介します。 - 臨界点を超えた先のコミュニケーションモデル
オープンソースプロジェクトのメンバー間でのコミュニケーションは人数が増えれば増えるほど面倒になります。それが臨界点に達するとき、負の反応は静かに出てくることになります。ここでは、巨大化したプロジェクトに適したコミュニケーションモデルを考えます。 - 足を引っ張りたがる人たち――その深層心理と対処法
あからさまに失礼な態度ではないがプロジェクトの進み具合に悪影響を与えている人たち――こうした人たちは実に扱いにくい存在です。ここでは、彼らはなぜそうするのかを考え、最良の対応について実例を挙げつつ考えます。 - 「空気が読める」開発者への道
あなたがオンラインのプロジェクトに参加しようとする場合、陥りがちなわなをうまく避けていく必要があります。ここでは、ケーススタディを交えながら、開発プロジェクトにおける最高の処世術を伝授しましょう。 - あなたの言葉はなぜ他人の心に響かないのか?
プログラマーとしては二流でもコミュニケーションスキルが優れている人は、結果としてプロジェクトをよい方向に引っ張ることになります。ここでは、オープンソースの世界で暮らす上で、あなた自身がうまくコミュニケーションを行う方法とプロジェクト内での円滑なコミュニケーションを維持する方法を説明します。 - 華やかな開発を支える無視されがちな活動
- オープンソース開発者との好ましい“契約”
- カネと開発者とプロジェクトの不思議な関係
- 開発プロジェクトをめぐるお金の流れ、その真相
- 合意と投票で構築されるOSS開発の社会構造
- “優しい独裁者”はこんな仕事に追われている
- 開発プロジェクトを支える名脇役たち
- バグ追跡システムのライフサイクルを再考する
- バージョン管理システムのすすめ
- バージョン管理システムが分かる13のキーワード
- メーリングリストを120%活用するテクニック
- コミュニケーションを促進する技術的な仕組み
- フリーソフトウェアの公開、その心構え
- フリーソフトウェアプロジェクトはなぜ失敗するのか
- 今日のフリーソフトウェア文化の始まった背景を知る
- 「フリー」と「オープンソース」の違い
- 新しいフリーソフトウェアプロジェクトをスタートさせる方法――概論
- 新しいフリーソフトウェアプロジェクトをスタートさせる方法――各論
- OSSライセンスの選択と適用――クイックスタート
- OSS開発、“はじめの一歩”で抑えておくべきポイント
content on this article is licensed under a Creative Commons License.