2008年01月17日

JPCERT/CCとの「脆弱性情報ハンドリング」の記録

はてなブックマークに登録

■ はじめに

「△△製のソフトウェア××に脆弱性が発見された」というニュースが連日のようにネットの上を行き交っています。 このブログの読者にはプログラム開発者の方も多いと思いますが、 自分の携わるソフトウェアの脆弱性を第三者から指摘された経験のある方はどのくらいおられるでしょう?

先日、筆者は「HttpLogger」というフリーソフトウェアのセキュリティホールを修正しました。 そのきっかけとなったのはJPCERT/CC(有限責任中間法人 JPCERT コーディネーションセンター)様から届いた 一通のメールでした。
それから私は同センターと連携し、10日余りの準備期間を経て修正ずみのモジュールの公開と 旧バージョンにおける脆弱性情報の開示を行いました。 この「脆弱性情報ハンドリング」と呼ばれるプロセスに関わったことは、一般的な知名度とは裏腹に 普段あまり身近な存在ではない「JPCERT/CC」の活動の一端に触れる機会を得たことを含め、 プログラム開発者として貴重な経験だったと考えています。
そこで、同センターのご理解とご協力に基づき、ここでの一連の経緯を公開することにしました。 ベンダ側の視点でのこういった記録はほとんど見かけませんので、情報として多くの方と共有できればと思います。


(※記事本文においては敬称を略させて頂きます)
(内容)

■ JPCERT/CC からの連絡?

(1日め)
11月も終わりに近づいたある日、一通のメールが届きました。
「KLab株式会社 担当者様」へ宛てられたこのメールは次のような内容のものでした。

・このメールがJPCERTコーディネーションセンター(JPCERT/CC)からの
 連絡であること
・JPCERT/CCの活動内容に関する説明
・HttpLoggerの脆弱性に関する情報が寄せられたためKLab側担当者と
 連絡をとりたい旨


文面を読んでしばらく考えました。JPCERTってあのJPCERTか?

「HttpLogger」というのはKLabのブログ「DSAS開発者の部屋」において11月初旬にフリーウェアとして公開したWindows用のプログラムで、担当者は私です。 そのプログラムに脆弱性があるとは大変気がかりな内容です。 しかし、この連絡が本物であるかどうかはまだわかりません。 何より、あんな地味なツールのことでわざわざJPCERTが?と不思議に思いました。

とりあえず対応を部内で相談したところ、「まずはこれがJPCERTからの正当な連絡であるとみなして返信すべきだろう。 ただしメールにPGP署名がないのも少々気になるため現時点では念のため連絡内容に注意を」 という、まっとうな結論になりました。

JPCERTコーディネーションセンター ○○様

KLab 株式会社の田辺と申します。ご連絡を頂きありがとうございます。

(引用略)

私が「HttpLogger」の開発を担当しております。
ご活動内容の社会的意義には平素より敬服しており、事故発生の抑止と
問題点の修正に向けてぜひご相談させて頂きたく存じます。
まずはとり急ぎ返信までにて、宜しくお願い致します。

         (引用後略)

30分ほどで以下の内容の返信が届きました。

・脆弱性に関する説明と対応手順について貴社にて相談を行いたい旨
・その候補日時の提示とスケジュールの打診

話が具体的になってきました。会って詳細を聞けば相手を確認することもできるでしょう。 しかし、私には地方で遠隔勤務を行っているという事情がありすぐには東京本社で会うことができません。 とは言え、今のところHttpLoggerの担当者は私一人なので、多忙な他のメンバーに代理出席を 依頼するのは気が引ける上に話の内容によっては何かと煩雑になりそうです。
結局、今後のことも考慮し、事情を説明した上でメールや電話でのやりとりを打診することにしました。

(2日め)
先方はその方法に合意を示し、詳細情報に関しては「内容に機微な情報を含むため、 可能であればPGPで暗号化したうえでお送りしたい」という意向を伝えてきました。 このことで、先方が機密を含む話題とそうでない話題とでは連絡方法を明確に区別していることを理解しました。 所定の手順でPGP公開鍵の交換と正当性の確認を行い、準備が整ったところでふたたび連絡がありました。 今後の進め方に関する大枠の説明です。

1. 脆弱性の詳細の説明(別途連絡)
2. KLab側での検証と脆弱性対策方針の検討
3. 脆弱性情報の一般公開日程の調整
4. KLab側サイトおよびJVN <http://jvn.jp/> で同時に情報公開を実施

うーん?何だかまだピンときませんが、どうやら「始まり」のようです。 もちろん、自分の作成したソフトウェアに脆弱性があるのならすぐにでも修正を行いたいところです。 とりあえずJVNにアクセスして記事を見てまわりました。

■ 脆弱性情報の開示 (JPCERT/CC->開発者)

(2日め続き)
ほどなく、暗号化されたメールが届きました。脆弱性の詳細説明を中心とする次のような内容です。

・本メールに記載の脆弱性情報はIPAより提供されたものであること

・本メールに記載の脆弱性情報は機密として扱わなければならないこと

・IPAからの提供情報について
 ・(検証を行った環境)
 ・(現象を再現させるための手順)
 ・(IPAへ届出のあった内容)

・今後の進め方について
 ・KLab側でHttpLoggerの脆弱性の検証を実施
 ・KLab側で脆弱性対策方針と所要日数の決定
 ・KLab側から一般へ公表する内容と公表方法の検討
    ↓↓↓
 これらの事項についてのKLab側の意向をもとに公表日の調整・決定を行う


なるほど、だいぶ様子がわかってきました。 現在は以下の状態であることが読み取れます。

1: 第三者からIPAに対してHttpLoggerの脆弱性に関する情報提供が

  あった
        ↓
2: IPAがそれを元に検証を行った
        ↓
3: 調整役であるJPCERT/CCがIPAより検証結果を含む情報提供を   受けた
        ↓
4: 開発者であるKLabがJPCERT/CCより事前開示を受けた
また、このメールには今後厳守しなければならない重要な注意点が明記されていました。

この情報は機密情報として十分に注意してお取り扱いください。
考え方を正しく把握しておくために、JPCERT/CC サイトで公開されている [脆弱性情報ハンドリング] - [ガイドライン] に目を通してみました。
http://www.jpcert.or.jp/vh/guideline.pdf (PDF書類)

JPCERT/CCが脆弱性情報をハンドリングすることの目的は「脆弱性関連情報を必要に応じて開示することで、脆弱性情報の悪用、または障害を引き起こす危険性を最小限に食い止める」ことにあるため、三者が足並みを揃えて向き合う「公表日」までは決して脆弱性の存在を漏らしてはならないということですね。 さらに、公表日に一般へ開示する情報はあくまでも脆弱性の概要であり、悪用される可能性のある詳細な情報は公表日以降も機密として扱わなければならない、と先方から説明を受けました。 悪用される可能性のある攻撃方法を含んだ詳細な脆弱性情報は、公表日以降も無用な攻撃を誘発しないよう取り扱いは慎重に、と先方から説明を受けました。

(2008.01.24 注記)
上記棒線箇所の表現について読者の方から規定外の事項では?とのご指摘をいただきましたが、実際には強制的な指示の類ではなく、むしろ初回対応であることに配慮しての助言のニュアンスであったことを申し添えておきます。ただし、元の表現にはたしかに大いに語弊がありますので、先方への確認を経て上記のより正確な表現にあらためることにしました。ご了承願います。


さて、メールには、まず公表日を決定するために開発者側での脆弱性の対策方針の検討と所要日数の見積もりが必要とあります。ここからはいよいよ問題の本質に向き合うことになります。

■ 対策および必要日数の検討・連絡 (開発者->JPCERT/CC)

(2日め続き)
さっそく、メールに記載のあった再現手順を試してみました。 その内容はまさにプログラム開発時に想定の漏れていた弱点を衝くものであり、 報告どおりの手順で問題の再現を確認することができました。 これはできるだけ早く修正しなければなりません。
ソースコードを調べてみると、幸い本件の修正自体はそれほど難しいものではありませんでした。 しかし、別の箇所に他の問題が潜在している可能性もあります。 そのため、プログラムの再チェックを行う過程においてさまざまなパターンでの攻撃を行い、 危険につながる可能性のある箇所をひとつずつ潰していく必要があると考えました。 そのため、見積り日数にはある程度の余裕を含ませておくことにします。
また、対応方法としては、新しいバージョンの作成と公開を行い、旧版の利用者へアップグレードを 呼びかける形をとることにしました。 このアナウンスは初回の公開時と同じブログ上で実施することがもっとも適切だと判断しました。

こういった個々の話題についてひと通りの判断を行い、以下の回答を送りました。

JPCERT/CC □□様

       (引用略)

 ご指摘の操作手順による検証を実施し、プログラムに含まれる問題の存在を確認
 いたしました。

 次の内容での対応を想定しています。
 ・プログラムの脆弱性を修正した新しいバージョンを作成する

 一連の対応には ○月○日 を起点として ○日間の日数を要するものと判断して
 います。当方としましては具体的な一般公表日時として「△月△日 △時」を希
 望いたします。
 なお、万一の想定外の状況により必要日数に変更が生じた場合には「JPCERT/CC
 ガイドライン」4-2 項に従いすみやかにご連絡させていただきます。

 当方では一般公表日時に次の内容の情報を公表します。

 ・HttpLogger バージョン 0.8.1 には脆弱性があり、この脆弱性を攻撃されると
  ユーザのブラウザ上で任意のコードが実行される可能性があること
 ・JPCERT/CC 様からの勧告を受け緊急にこの問題を修正したバージョンを作成し
  た旨とユーザへのバージョンアップの呼びかけ
 ・謝辞、リンク等

 公表は、弊社ブログ (http://dsas.blog.klab.org/) 上で行います。
 また、修正済みプログラムをブログ内の当該記事ページよりダウンロード可能な
 状態とします。

       (引用後略)


(3日め)
翌日、先方からは上記の内容を確認した旨に加え、公表日についてはIPAを含めての調整が必要であるため 確定に若干の時間がかかる旨と、先方の想定する候補日についての連絡がありました。

■ 公表日の連絡 (JPCERT/CC->開発者)

(4日め)
先方から公表日決定の連絡が届きました。

・IPAとの調整を経て決定した公表日時
  2007年12月07日(金)13:00 KLab側サイトにて情報公開
  2007年12月07日(金)15:00 JVNにて情報公開

・KLab側の事情により延期が必要となった場合には再調整が可能であること

・公開に際して必要な準備等をこのあと別メールで連絡する旨

情報の公開時刻は各者間で完全に同期させるのではなく、開発者側が数時間先行し、 その完了を確認してからJPCERT/CC側が追随するという考え方のようです。 たしかに、対策方法の詳細がもっぱら開発者側の公開情報内に含まれることを考えると、 不慮の事故等でJVN分の情報が先行して露出した場合の危険性は容易に想像ができます。

■ 公表に必要となる情報の提示依頼 (JPCERT/CC->開発者)

(4日め続き)
その日のうちにふたたび連絡がありました。これが、前のメールに 書かれていた「必要な準備等」の内容です。

・12月6日(木)夕刻までに必要となるKLab発の情報について

 ・KLab側で情報公開を行うサイトのURL(可能なら公開記事の文面も)
 ・ベンダステータス情報(JVN上で掲載するKLab側公開情報へのリンクや
  簡単な説明を含む記事)

・JPCERT/CCからはJVNに掲載する記事の草稿をおって提示する予定であり
 その際にはKLab側で事実関係等を確認してほしい旨

・KLab側サイトからの情報公開は必ず決定日時どおりの実施が必須であること
 →サーバ障害等に遭遇した場合は再調整のために直ちにJPCERT/CCへ連絡を

■ プログラム修正・提示する記事の作成 (開発者)

(5-9日め)
最終的にもっとも重要となるのは、既存の脆弱性への対策として一般へ公開する内容の確実さです。 今回の場合、開発者側が対策として決定したのは「新しいバージョンへのアップグレード」という 方法ですから、新バージョンの開発には細心の注意が必要です。
手元では今回指摘にあった脆弱性の修正をすでに終えています。しかし、前述の通り プログラムにはまだ他の弱点が残っているかもしれません。 実際の攻撃の手口を参考にしながらさまざまなパターンの攻撃とソースコードの確認を繰り返し、 この4日間で多くの修正を行いました。 用意した修正項目と試験項目の消化を終えた9日めに部内限定でベータ版を公開し、 修正内容の説明と新しいバージョンへの攻撃テストの依頼を行いました。

■ ベンダステータス情報および KLab 側公開記事ドラフトの提示
(開発者->JPCERT/CC)

(9日め続き)
先日提示を求められた情報について12/04に次の内容で返信しました。

JPCERT/CC  □□様

       (引用略)

・弊社側情報公開サイトのURL

 弊社からの情報公開には (http://dsas.blog.klab.org/) を使用します。
 記事本体の URL については以下をご参照下さい。

・弊社側公開記事内容

 本信末尾に記載の「● KLab 側公開情報」をご参照下さい。
 公開までに文言などの若干の修正を行う可能性はありますが、全体としては
 おおむね確定の状態とお考え下さい。もし、全体の文脈に関わりのある変更を
 行った場合には12月06日(木)夕刻までに再度お送りします。

・ベンダステータス情報

 本信末尾に記載の「● ベンダステータス情報」の内容でご入力いただきたい
 と考えております。宜しくご確認下さい。
 なお、ここに記載している URL の XXXX 部分はダミーです。正式な URL は
 ご指定の12月06日(木)夕刻までにお知らせすることも可能なのですが、
 もしご事情が許せば12月07日(金)早朝7時までお待ちいただけません
 でしょうか?念のためご都合をお聞かせいただければ幸いです。


● ベンダステータス情報
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
本脆弱性への対策方法は以下の URL で公開しています。

 「HttpLogger」バージョンアップのお知らせ(2007/12/07)
 http://dsas.blog.klab.org/archives/xxxxxxxx.html


● KLab 側公開情報
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
「HttpLogger」バージョンアップのお知らせ(2007/12/07)

■ はじめに

Windows 用フリーウェア「HttpLogger」のバージョンアップを行いました。
今回の新しいバージョン 0.8.2 にはセキュリティに関する重要な修正が含
まれています。
旧バージョンをご利用中の方はこのバージョンへのアップデートをお願い
いたします。

       (引用後略)

ちなみにURL情報に関する打診はもっぱらブログの システムとのかねあいによるものです。 事前に非公開状態で記事を用意しておくことは可能ですが、 ヘッダに固定表示される日付は作成日のものとなる仕組みなのです。 明示的に12/07に公開する記事なのに過去日付が表示されるのは 感心しないため先方の都合を確認することにしました。

■ JVN掲載記事ドラフトの確認 (JPCERT/CC <-> 開発者)

(9日め続き)
その日の内に次の内容の返信がありました。

・KLab側の情報公開用URLの提示期限を12月7日(金)12時まで延期する旨

・JPCERT/CCで作成したJVN公開記事初版の文面とその内容確認の依頼

URL連絡の件は了承を得られたようです。また、先方から提示されたJVN公開文書ドラフトには ベンダステータス情報としてこちらが伝えた内容が反映されています。 ドラフトを確認し、対象バージョンに関する表記内容について一点質問をかねて 指摘を行いました。

(10日め)
翌日、「貴社からのご意見およびIPAとのレビューを終えたJVNドラフトを本メールの 末尾に添付いたしますのでご確認ください」という連絡が届きました。
折り返し、その内容に異存のない旨と2日後の手筈に関する最終確認のメールを送りました。 先方との事前調整はひとまず終わりです。

■ プログラムの最終確認 (開発者)

(10-11日め)
いよいよ終盤です。対象とするすべてのプラットフォームにおいてプログラムの最終チェックを行いました。 この過程で脆弱性対策に関連のある定数を一箇所変更し、脆弱性に直接関係しない一箇所の修正を行いました。
こうして HttpLogger バージョン 0.8.2 が完成しました。

■ 公表日

(12日め)
公表日12/07の早朝、ブログに新しい記事ページを作成し、先方へ次のメールを送りました。

JPCERT/CC □□様

       (引用略)

大変お待たせしました。弊社記事の URL をお知らせいたします。
■「HttpLogger」バージョンアップのお知らせ(2007/12/07)
http://dsas.blog.klab.org/archives/51149337.html

・当方の準備は予定通りすべて整っており、本日(12/07) 13:00 に
 上記の URL で記事の公開を行います
・不慮の状況に遭遇した場合には直ちに電話で、無事に公開を開始
 (=公開作業を完了)しましたらメールでその旨をご連絡差し上
 げます

       (引用後略)

先方より了解の返信が届き、すべての準備が整いました。

予定通り13時に次の記事を公開しました。
「HttpLogger」バージョンアップのお知らせ(2007/12/07)
http://dsas.blog.klab.org/archives/51149337.html


続いて15時にJPCERT/CCにより以下の記事が公開されました。
JVN#02854109 HttpLogger におけるクロスサイトスクリプティングの脆弱性
http://jvn.jp/jp/JVN%2302854109/index.html
 Japan Vulnerability Notes/ベンダーからの情報
 http://jvn.jp/jp/JVN%2302854109/353107/index.html


こうして、脆弱性情報の一般公開が無事に完了しました。

最後に、KLab技術者サイトにも以下のアナウンスを掲載しました。

Windows用フリーウェア「HttpLogger」の新バージョン 0.8.2 を公開しました。

DSAS開発者の部屋:「HttpLogger」バージョンアップのお知らせ(2007/12/07)
http://dsas.blog.klab.org/archives/51149337.html

この新しいバージョンにはセキュリティ上の脆弱性に関する修正が含まれます。
旧バージョンをご利用中の方はアップデートをお願いいたします。


いわゆる「脆弱性」は大手ベンダ製の有名なソフトウェアばかりに含まれているわけではありません。 むしろ脆弱性を抱えたまま誰にも気づかれずどこかで粛々と動いているソフトウェアは 数多く存在することでしょう。 HttpLoggerにしても出自は研究開発の一環で作成した実験的プログラムであり、 フリーソフトとして陽の目を見ることがなければ今回指摘を受けた脆弱性に 気づかずにいたかも知れません。 そういう意味においても今回の経験は教訓に富む貴重なものだったと考えています。 末筆となりましたが、JPCERT/CC様、IPA様ならびに脆弱性をご報告頂いた発見者の方に あらためて御礼申し上げます。
klab_gijutsu2 at 10:14│Comments(0)TrackBack(0)win 

トラックバックURL

この記事にコメントする

名前:
URL:
  情報を記憶: 評価: 顔   
 
 
 
Blog内検索
Archives
このブログについて
DSASとは、KLab が構築し運用しているコンテンツサービス用のLinuxベースのインフラです。現在5ヶ所のデータセンタにて構築し、運用していますが、我々はDSASをより使いやすく、より安全に、そしてより省力で運用できることを目指して、日々改良に勤しんでいます。
このブログでは、そんな DSAS で使っている技術の紹介や、実験してみた結果の報告、トラブルに巻き込まれた時の経験談など、広く深く、色々な話題を織りまぜて紹介していきたいと思います。
最新コメント